Checkout V2: Move to single-transaction Purchases

[curiousepic]

When the Checkout V2 adapter was initially implemented, it seems that the Checkout API couldn't perform a refund on an auto-captured authorizations (ie, single-transaction purchase), so Purchase used a multi-response authorization and capture call.

We have recently noticed intermittent Purchases that the adapter considers successful but in fact the Capture response was a 404. According to Checkout, this may be due to their id for the authorization not having yet been instantiated before the Capture reached them. So the multiresponse is too fast for its own good, and also the adapter's success criteria isn't sufficient to catch a failed Capture as part of a Purchase.

However, it seems that the constraint on refunds has since been removed. So, we can switch to a single-transaction Purchase, by not setting the capture field as false. There should be no effective difference in terms of the resulting Response.

Remote: 33 tests, 80 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed

Unit: 29 tests, 129 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications 100% passed

[curiousepic]

@molbrown Thanks for the scrutiny - I can't find any reference in Docs that this is would be a merchant-level toggle, nor in their sandbox UI, and Nicolas' communications in our internal ticket doesn't indicate this either. I expect that "if applicable" refers to whether it's a payout instead of a payment, which uses the same call. In any case, I'll see if we can get Nicolas to take a look at the PR.

[nicolas-maalouf-cko]

Hi all,

Thanks for your help with this one.

"If applicable" is there because some alternative payment methods as well as payout to cards don't involve captures.

When Capture is set to true (or left to its default value) in a card payment request, we automatically queue a capture after the authorisation is successful. Note that the synchronous response is still the one related to the authorisation and not the capture.

The 403s obtained in some tests are most likely because the automatic capture hadn't been executed yet, which resulted in the refund's failure.

Would this change affect both the Shopify and Spreedly integrations?

Kind regards

[curiousepic]

@nicolas-maalouf-cko Thanks for the info! It will affect Shopify, but as a reminder, only if/when they accept it internally, not on merging into this repo. Tagging @activemerchant/shopify-payments-devs as an FYI

Also, I'll add a short sleep to the refund remote tests.

[nicolas-maalouf-cko]

One last think I'd recommend is testing declines and other scenarios on a sandbox test store: https://docs.checkout.com/testing/response-code-testing

Would it be possible?

[curiousepic]

It would be good to move to testing failed cases via those amount codes. I assume these were not available when the adapter was first built, so we are primarily testing failed cases via a bad card number, but this actually invokes fail-by-error rather than proper decline/invalid responses. Thanks for pointing that out. I will create a separate PR to add a few of those just so we have at least some coverage in that respect.

In any case, some manual spot checks invoking responses via amount codes do pass well with this change 👍

[curiousepic]

Marking this "of interest" before a cleanup of stale PRs