Skip to content
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

Merged
merged 20 commits into from
Dec 10, 2019

Conversation

ahmetoz
Copy link
Contributor

@ahmetoz ahmetoz commented Dec 2, 2019

#64

Todos:

extension/docs/IntegrationGuide.md Outdated Show resolved Hide resolved
extension/docs/IntegrationGuide.md Outdated Show resolved Hide resolved
ahmetoz and others added 3 commits December 3, 2019 20:05
Co-Authored-By: andreas Halberkamp <andreas.halberkamp@commercetools.de>
Co-Authored-By: andreas Halberkamp <andreas.halberkamp@commercetools.de>
@ahmetoz ahmetoz changed the title adding details related 'authorization' CTP transaction. move 'charge' transactions to 'authorization' transactions according to the adyen best practices. Dec 3, 2019
@ahmetoz ahmetoz marked this pull request as ready for review December 4, 2019 09:44
extension/docs/IntegrationGuide.md Outdated Show resolved Hide resolved
extension/docs/IntegrationGuide.md Outdated Show resolved Hide resolved
@ahmetoz ahmetoz changed the title move 'charge' transactions to 'authorization' transactions according to the adyen best practices. #64 move 'charge' transactions to 'authorization' transactions according to the adyen best practices. Dec 4, 2019
extension/docs/CancelRefundPayment.md Outdated Show resolved Hide resolved
extension/docs/IntegrationGuide.md Outdated Show resolved Hide resolved
extension/docs/IntegrationGuide.md Outdated Show resolved Hide resolved
extension/docs/IntegrationGuide.md Outdated Show resolved Hide resolved
extension/docs/IntegrationGuide.md Outdated Show resolved Hide resolved
ahmetoz and others added 3 commits December 4, 2019 17:44
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>
Comment on lines 7 to 9
"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",
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +6 to +8
"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\"",
Copy link
Contributor

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.

Copy link
Contributor Author

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')
Copy link
Contributor

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?

Copy link
Contributor Author

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?

notification/test/unit/notification.handler.spec.js Outdated Show resolved Hide resolved
@ahmetoz ahmetoz requested a review from LEQADA December 9, 2019 09:02
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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.

@ahmetoz ahmetoz merged commit 77f9cba into master Dec 10, 2019
@ahmetoz ahmetoz deleted the update-first-transaction-type branch July 7, 2020 14:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants