-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#64 move 'charge' transactions to 'authorization' transactions according to the adyen best practices. #85
Conversation
Co-Authored-By: andreas Halberkamp <andreas.halberkamp@commercetools.de>
Co-Authored-By: andreas Halberkamp <andreas.halberkamp@commercetools.de>
Co-Authored-By: Roman Butenko <roman.butenko@commercetools.de>
Co-Authored-By: Roman Butenko <roman.butenko@commercetools.de>
Co-Authored-By: Roman Butenko <roman.butenko@commercetools.de>
extension/package.json
Outdated
"test": "npm run unit && npm run integration", | ||
"unit": "nyc mocha --exit --timeout 30000 --full-trace test/unit/**/*.spec.js", | ||
"integration": "mocha --exit --timeout 30000 --full-trace test/integration/**/*.spec.js", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be confusing to print test coverage only based on unit tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"test": "npm run unit && npm run integration", | ||
"unit": "nyc mocha --check-leaks --timeout 30000 --full-trace --recursive \"./test/unit/**/*.spec.js\"", | ||
"integration": "nyc mocha --check-leaks --timeout 30000 --full-trace --recursive \"./test/integration/**/*.spec.js\"", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
npm run test
will print code coverage twice. I think it's better if the implementation of the test
script remains the same as before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const { body: { results: [ paymentBefore ] } } = await ctpClient.fetch(ctpClient.builder.payments) | ||
expect(paymentBefore.transactions).to.have.lengthOf(1) | ||
expect(paymentBefore.transactions[0].type).to.equal('Authorization') | ||
expect(paymentBefore.transactions[0].state).to.equal('Initial') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So there will be no transaction in Initial
state?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
according to our documentation, it's better to use pending in this test, it's pending state because the payment will go first to the extension module, so notification could trigger after some operations which are done by extension module, right?
Co-Authored-By: Roman Butenko <roman.butenko@commercetools.de>
Co-Authored-By: Hasan <LEQADA@users.noreply.github.com>
If the transaction is already charged, Adyen will do refund. | ||
1. In `Payment.transactions`, extension module finds the first transaction with `type='Charge' and state='Success'`. | ||
|
||
- Both transaction types work the same, because Adyen will always pick the right action for the current transaction. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Both transaction types work the same, because Adyen will always pick the right action for the current transaction. | |
- Both charge and refund is processed by Adyen in a similar manner and it will automatically pick the right action for the current transaction. |
#64
Todos: