[Deferred intent] Card - Handle capture-later transactions

[a-danae]

Acceptance criteria

• The following critical flow Merchant -> Manual capture must work as described
• It must work with both regular and 3DS cards
• Errors must be handled gracefully:
  • A relevant, user-friendly message must be shown to shoppers
  • A relevant note must be added to the order
  • A detailed message of the error must be logged to the log files if enabled
  • The order status must reflect the payment status

[james-allan]

I've tested the following scenarios and they all passed on the latest add/deferred-intent branch.

• [x] Block Checkout
  • [x] Standard Card
    • [x] Capture from Stripe Dashboard
    • [x] Capture from WooCommerce order
  • [x] SCA/3DS Card ^{* 📝}
    • [x] Capture from Stripe Dashboard
    • [x] Capture from WooCommerce order
• [x] Classic Checkout
  • [x] Standard Card
    • [x] Capture from Stripe Dashboard
    • [x] Capture from WooCommerce order
  • [x] SCA/3DS Card ^{* 📝}
    • [x] Capture from Stripe Dashboard
    • [x] Capture from WooCommerce order

In all cases, the order was originally placed on-hold with an order note with detailed instructions:

^{Authorized payment order notes}

After the order is captured, it has transaction complete notes too.

^{Authorized payment order notes}

Support for auth/capture was added in https://github.com/woocommerce/woocommerce-gateway-stripe/pull/2753 (commit: https://github.com/woocommerce/woocommerce-gateway-stripe/commit/b67203690249e96cb7b41cac1413d0e71524c1ac) when prepare_payment_information_from_request() was introduced with the capture_mode param set when setting up and confirming the intent.

The actual capturing of the payment either via the Stripe or WooCommerce dashboards didn't require any changes - the existing functionality just worked. 😀

* 📝 When paying with a SCA/3DS card, the order notes appear to be missing the charge ID (see screenshot below). This appears to be the only issue I came across while testing auth/capture.

[james-allan]

When paying with a SCA/3DS card, the order notes appear to be missing the charge ID (see screenshot below). This appears to be the only issue I came across while testing auth/capture.

PHP Warning:  Attempt to read property "id" on bool in /wp-content/plugins/woocommerce-gateway-stripe/includes/abstracts/abstract-wc-stripe-payment-gateway.php on line 528

There's also this error message that accompanies the issue with SCA/3DS payments.

[csmcneill]

It might not fall in the scope of this issue, as I'm not sure if this only affects deferred intent. During some testing I'm doing for our Stripe documentation, I'm finding that saved payments cannot be used when auth + capture is enabled.

Attempting to pay via a saved payment method while auth + capture is enabled produces the following error on the front end:

Sorry, we are unable to process your payment at this time. Please retry later.

And this pops up in the logs:

Error: stdClass Object
(
    [error] => stdClass Object
        (
            [message] => The following payment method types ["giropay", "eps", "bancontact", "ideal", "sepa_debit", "p24"] can only be used with PaymentIntents that have capture_method=automatic. Please retry by creating a PaymentIntent with capture_method=automatic.
            [request_log_url] => https://dashboard.stripe.com/test/logs/req_OHRHNmYRRAy9Wv?t=1703627670
            [type] => invalid_request_error
        )

)

If this isn't related to deferred intent, please let me know and I'll be happy to open up a separate issue.

[james-allan]

Hey @csmcneill can you provide some replicating instructions?

I've enabled auth and capture, created a saved payment method via the my account page and attempted to use that saved payment method to make a purchase. While testing on the latest version of Stripe, I couldn't replicate the error you mentioned.

We're you testing on the latest public version of Stripe or the working deferred intent branch (add/deferred-intent)?

If you were on the latest public version, then you might need to create a separate issue as this issue is specifically to do with the UPE with deferred intents project which isn't live at the moment.

---

Something else I noticed from the error message you included from your log is that it mentions that "giropay", "eps", "bancontact", "ideal"... cannot be used with auth and capture.

I have a feeling that you might be trying to use an APM that doesn't support auth and capture. If that's the case, the bug likely involves adding an APM saved payment method while Auth and Capture is disabled and then attempting to use that saved method while Auth and capture is enabled. 🤔

In any case, if you can let me know what branch you were testing on, whether you had UPE enabled in WC > Payments > Stripe > Settings > Advanced and whether the payment method you were using was a saved card or perhaps a different method Giro pay, Sepa etc, then I should be able to point you in the right direction.

[csmcneill]

Thanks for looking into this @james-allan! I was using the latest stable release in my testing, so I wasn't using the deferred intent branch.

I'll do a bit more digging on my end, and I'll open up a fresh issue with some replication steps :)

[james-allan]

I've retested the lates add/deferred-intent branch with auth and capture enabled.

Block checkout

• [x] saved card
• [x] new card
• [x] 3DS card
• [x] Subscription free trial Classic checkout
• [x] saved card
• [x] new card
• [x] 3DS card
• [x] Subscription free trial

Notes - In all the scenarios above the following expected outcome was observed:

• On-hold order and an uncaptured charge in Stripe.
• Processing the order captures the payment.
• Because of the free trial, no payment is captured in that case.

I noticed while testing that all the APMS are shown on the classic checkout even though auth & capture is enabled.

I'll file a separate issue for that. Closing this one as auth and capture itself is working as expected.