gateway->authorize without return_url to allow "next_action": {"type": "use_stripe_sdk"}

[R00118189]

I followed example on https://github.com/stripe/stripe-payments-demo and would like to use stripe.handleCardAction(response.data.payment_intent_client_secret) to get a popup not redirect as currently package is offering
at this moment i commented this section

// if ($this->getConfirm()) {
//     $this->validate('returnUrl');
//     $data['return_url'] = $this->getReturnUrl();

to get use_stripe_sdk in the response and use frontend stripe.handleCardAction

also i would add

public function isFurtherActionRequired()
    {
        if ($this->getStatus() === 'requires_action' || $this->getStatus() === 'requires_source_action') {
            return (!empty($this->data['next_action']) && $this->data['next_action']['type'] === 'use_stripe_sdk');
        }
    }

my flow is as follows:

• Create PM on frontend with Stripe.js
• Create PI on backend and when PI status requires further action i send to frontend PI secret and ask Stripe.js to do handleCardAction
• Go back to backend and confirm the PI
• Get status of the PI as succeeded & Fulfil the order on Backend

All in one page No redirects

[domis86]

Yes - i use similar flow which is described here: https://stripe.com/docs/payments/payment-intents/web-manual

I did following workaround to make this flow work:

        $paymentIntentAuthorizeRequest = $paymentIntentGateway->authorize();

        $paymentIntentAuthorizeRequest->setPaymentMethod($paymentMethodId);
        $paymentIntentAuthorizeRequest->setDescription('My Order '.$orderUuid);
        $paymentIntentAuthorizeRequest->setCustomerReference($stripeCustomer->getId());
        $paymentIntentAuthorizeRequest->setAmount($orderPrice);
        $paymentIntentAuthorizeRequest->setCurrency($orderCurrency);
        
        $paymentIntentAuthorizeRequest->setConfirm(true);
        $paymentIntentAuthorizeRequest->setReturnUrl(' ');

        $data = $paymentIntentAuthorizeRequest->getData();

        // Don't send 'return_url' because we want "Stripe SDK" to handle PaymentIntent on frontend side
        // If 'return_url' would be sent then it will be the "redirect way" - read more here: https://stripe.com/docs/payments/3d-secure-iframe
        // Also unset 'capture_method' so it will be default ('automatic') see: https://stripe.com/docs/api/payment_intents/create#create_payment_intent-capture_method
        unset($data['return_url'], $data['capture_method']);

        /** @var \Omnipay\Stripe\Message\PaymentIntents\Response $paymentResponse */
        $paymentResponse = $paymentIntentAuthorizeRequest->sendData($data);

Can you try similarily?
If works for you too then someone should propose PR with changes that add option to enable such flow :)

[R00118189]

Dominik, your flow works however there is one more obstacle with application_fee which shall be upgraded to application_fee_amount as per new Payment Intents API

$data['application_fee_amount'] = $data['application_fee'];
unset($data['application_fee'], $data['return_url'], $data['capture_method']);

does the job until the package is fully upgraded

[gmoreira]

I discussed this with Stripe Support today and they informed me that while return_url is only available when confirm=true, it is not mandatory to specify. The documentation is actually not clear about this, if its required or optional when confirm=true, which they confirmed for me today is optional.

What I have found is that when confirm=true and a return_url is specified, this is triggering the Manually handling 3D Secure authentication with redirect workflow, which requires the browser client code to manually handle redirecting the the redirect url provided for the PaymentIntent.

If the return_url is actually not specified and confirm=true, the PaymentIntent response can contain a client_secret that (if applicable) is actually compatible with Dynamic 3D Secure workflow which uses the pre-built modal inside Stripe Elements to handle the process without manual redirects via stripe.handleCardAction.

[gmoreira]

PR #155 has been introduced to address the issue with the Application Fee Amount field.

[domis86]

@gmoreira

If the return_url is actually not specified and confirm=true, the PaymentIntent response can contain a client_secret that (if applicable) is actually compatible with Dynamic 3D Secure workflow which uses the pre-built modal inside Stripe Elements to handle the process without manual redirects via stripe.handleCardAction.

I use it like this with the workaround i specified above #152 (comment) - so i guess something similar should be added as feature to Omnipay Stripe.

[gmoreira]

Ive extended PR #156 to include helper methods $response->isStripeSDKAction() and $response->getClientSecret().