Stripe throws incomplete payment after first subscription with SCA

[marcbelletre]

I'm working on updating my project with Cashier v10.0.0-beta.2 and the new Payment Intents API for a few days now and I'm still having issues with my customers having to provide their card details and 3D secure twice. I can't say if I did something wrong or if this is a Cashier related issue so I'm asking here.

I updated my integration following these instruction.

My new customers have to fill a form with their personal information and select one or many subscription plans. At the end of the form there is a Stripe card element. Before the user submits the form, I use Stripe's handleCardSetup method to verify the payment and then submit the form to my controller which creates the subscription(s).

The form contains a SetupIntent key which is generated by the controller before returning the view.

$setupIntent = (new User)->createSetupIntent();

return view('front.auth.register', ['setupIntent' => $setupIntent]);

This is my jQuery code for handling Stripe API.

$('#register-form').on('submit', function(e) {
    e.preventDefault();

    // Disable submit button
    $(this).find('button[type=submit]').prop('disabled', true);

    var clientSecret = $('#setupintent-secret').val();
    var cardholderName = $('#cardholder-name').val();

    stripe.handleCardSetup(
        clientSecret, cardElement, {
            payment_method_data: {
                billing_details: {
                    name: cardholderName
                }
            }
        }
    ).then(function(result) {
        if (result.error) {
            // Inform the user if there was an error
            $('#card-errors').html(result.error.message).slideDown(200);

            // Re-enable form submission
            $('#register-form').find('input[type=submit]').prop('disabled', false);
        } else {
            // Insert the payment method ID into the form so it gets submitted to the server
            var form = $('#register-form');

            form.append($('<input type="hidden" name="stripePaymentMethod" />').val(result.setupIntent.payment_method));

            // Submit form
            form.get(0).submit();
        }
    });
});

I get the Stripe's 3D secure popin everytime I submit the form, but when I confirm the payment using the Complete authentication button, the SubscriptionBuilder's create() method throws an IncompletePayment exception and I have to provide all the card details again. This seems wrong as I already verified the payment with 3D secure.

Here is the code which is handling the new subscription in my controller:

$subscription = $user->newSubscription($planType, $planId);

try {
    // Create subscription
    $subscription->create($request->input('stripePaymentMethod'), [
        'email' => $user->email
    ]);
} catch (IncompletePayment $e) {
    if ($e instanceof \Laravel\Cashier\Exceptions\PaymentActionRequired) {
        return redirect()->route('confirm_payment', [$e->payment->id, 'redirect' => route('home')]);
    } else {
        dump($e); die;
    }
}

[driesvints]

Normally after you've created the subscription it's already in your DB and in Stripe and the payment should be "incomplete" until you've confirmed 3D Secure.

Couple of things:

• Did you properly set up your webhooks and are they actively delivering the Stripe events to your app? This will mark your subscription as active as soon as you've passed 3D Secure. This is noted in the upgrade guide here: https://github.com/laravel/cashier/blob/master/UPGRADE.md#webhooks
• Can you lookup the payment in Stripe to see what its status is after you've created the subscription and before you've done the 3D Secure check?

[marcbelletre]

Thank you for your help.
I have set up the webhooks correctly in Stripe but the payments are marked as incomplete even after the 3D secure check. Here are some screenshots of my subscription process:

When I hit the submit button in my form I get this popin.

Then I get redirected to the payment confirmation page.

In my Stripe account I can see that the payment is indeed marked as incomplete.

[driesvints]

The first 3D Secure check is because of the setup intent. You're verifying the card for later recurring use so you don't need to do the 3D Secure check when your subscription renews.

But it is weird that you're prompted again. In theory this could happen when your card is declined.

If your submit the payment conformation screen is the subscription then marked as active?

Can you maybe also check the payment details there from your last screenshot. There should be a "A new payment pi_xxxx for xxx was created" event at the bottom. I'm especially looking to see what the value of the "status" column is.

[marcbelletre]

Yes if I submit the payment in the confirmation screen the payment succeeds and the subscription becomes active.

Here are the events (sorry it's written in french)

• 13/08/2019 14:55:53 Invoice updated
• 13/08/2019 14:55:53 Invoice marked as paid
• 13/08/2019 14:55:53 Payment intent pi_1F6ygiLwhwXHyztNzlfaKx2Y successed
• 13/08/2019 14:55:53 johndoe@test.com has been invoiced 202,80 €
• 13/08/2019 14:01:17 Draft invoice finalized
• 13/08/2019 14:01:17 Draft invoice created
• 13/08/2019 14:01:17 Payment requires new action
• 13/08/2019 14:01:17 Payment failed
• 13/08/2019 14:01:16 New payment intent pi_1F6ygiLwhwXHyztNzlfaKx2Y for 202,80 €

We can see that the payment failed the first time while the 3D secure step was successful.

[driesvints]

Can you open the 13/08/2019 14:01:16 New payment intent event and tell me what the status looks like?

[marcbelletre]

Sure. The status is requires_payment_method.
This is weird because I did create the payment method with stripe.handleCardSetup().

Here is the full event:

{
  "object": {
    "id": "pi_1F6ygiLwhwXHyztNzlfaKx2Y",
    "object": "payment_intent",
    "amount": 20280,
    "amount_capturable": 0,
    "amount_received": 0,
    "application": null,
    "application_fee_amount": null,
    "canceled_at": null,
    "cancellation_reason": null,
    "capture_method": "automatic",
    "charges": {
      "object": "list",
      "data": [
      ],
      "has_more": false,
      "total_count": 0,
      "url": "/v1/charges?payment_intent=pi_1F6ygiLwhwXHyztNzlfaKx2Y"
    },
    "client_secret": "pi_1F6ygiLwhwXHyztNzlfaKx2Y_secret_Tg0mDa1wOZmqRHA8rVy8tN8dZ",
    "confirmation_method": "automatic",
    "created": 1565697676,
    "currency": "eur",
    "customer": "cus_FcD60jlH4ByrrM",
    "description": "Payment for invoice 098EAC47-0001",
    "invoice": "in_1F6ygiLwhwXHyztNFyuSbWhd",
    "last_payment_error": null,
    "livemode": false,
    "metadata": {
    },
    "next_action": null,
    "on_behalf_of": null,
    "payment_method": null,
    "payment_method_options": {
      "card": {
        "request_three_d_secure": "automatic"
      }
    },
    "payment_method_types": [
      "card"
    ],
    "receipt_email": null,
    "review": null,
    "setup_future_usage": null,
    "shipping": null,
    "source": null,
    "statement_descriptor": null,
    "statement_descriptor_suffix": null,
    "status": "requires_payment_method",
    "transfer_data": null,
    "transfer_group": null
  }
}

[driesvints]

Thanks. That's really odd. You're sure $request->input('stripePaymentMethod') contains the payment method identifier from the card you've set up?

What happens behind the scenes is that this card is used as your default card. If you've previously already set a default card with the setup intent you shouldn't need to pass this. If this if your first setup then you'll need to pass it. There's a default payment method parameter when creating subscriptions which says the following:

ID of the default payment method for the subscription. It must belong to the customer associated with the subscription. If not set, invoices will use the default payment method in the customer’s invoice settings.

So your customer's default payment method should be used (which was set right before the creation).

[marcbelletre]

I just dumped $request->input('stripePaymentMethod') and got pm_1F70OFLwhwXHyztNjSrT0pCw so it looks correct.

I'm using this code in a signup form so the user actually doesn't even exist before creating the subscription. When I submit the form, I create the user then their subscriptions so I'm sure they can't have a default payment method already.

[driesvints]

@marcbelletre The default payment method is definitely set because you're passing the payment method is to the create method of the subscription builder. If you trace this down you'll see that the default payment method is set on the customer.

[marcbelletre]

I don't understand. I meant that there couldn't be a default payment method before the user registers because they didn't exist. What I'm doing is setting up the payment method with the JS API. I get a payment method ID which I append to the form and then I submit the form. Then, my controller creates the user and the subscription using the payment method ID.

I can see in Stripe that my customer has a default payment method but the first payment is declined and needs additional action.

I just tried creating the Stripe customer and attaching the payment method before creating the subscription with the same result.

// Create user and attach payment method
$user->createAsStripeCustomer();
$user->updateDefaultPaymentMethod($request->input('stripePaymentMethod'));

// Create subscription
$subscription = $user->newSubscription($planType, $planId);
$subscription->create(null, [
    'email' => $user->email
]);

[driesvints]

The subscription builder calls the method below right before creating the subscription and will create a customer in stripe and set the payment method you provided as the default payment method:

https://github.com/laravel/cashier/blob/cdfcdd29e4c4ee9b91e314848c1a3220c3498fda/src/SubscriptionBuilder.php#L239-L248

[marcbelletre]

Yes I saw that already, just wanted to double check. I still can't figure out why the first payment gets declined. Correct me if I'm wrong but it looks like when Stripe creates the payment_intent.created event, the default payment method is not set because the status is requires_payment_method. Do you have an idea why?

By the way, the test card I'm using is 4000 0025 0000 3155. The Stripe docs say:

This card requires authentication for one-time payments. However, if you set up this card and use the saved card for subsequent off-session payments, no further authentication is needed. In live mode, Stripe dynamically determines when a particular transaction requires authentication due to regional regulations such as Strong Customer Authentication.

[driesvints]

Ah, but you're not off-session, remember? You're on-session here. So that might be it. If you use a testing card then it's probably normal that it triggers 3D Secure because it's built in to trigger it.

Remember that 3D Secure can still happen by an off-chance in every single situation when you perform a payment. It's rare when you use the setup intent but it can still happen.

[marcbelletre]

I know I'm not off-session but I'm worried about the fact that users could have to provide their payment details and go through the 3D secure process twice in live mode right after subscribing. While I agree that this could happen at any time for the next payments, this scenario should never happen right after the first payment because we already validated it with 3D secure.

If you have a look at this scenario described in the Stripe guide, which is similar to the one I'm trying to build, the first payment is always authorized after a single 3D secure check.

Also the testing card I'm using is the one that should trigger 3D secure for the first payment only. I tried with 4000 0000 0000 3220 as well with the same results.

The second payment form works because it has a payment intent ID and uses the stripe.handleCardPayment() method instead of stripe.handleCardSetup(). Could it have something to do with the fact that we are using SetupIntents instead of PaymentIntents? Should we create a PaymentIntent as soon as we show the subscription form?

As per the Stripe documentation, SetupIntents are used to "set up your customer's card without immediately collecting a payment". In my case and I guess I am not the only one, we also need to immediately collect the first payment without asking the user to fill the credit card input twice.
In the docs, Stripe recommends "creating a PaymentIntent as soon as the amount is known, such as when the customer begins the checkout process".

[driesvints]

I really think this is because of the testing cards and that this won't happen in a live environment but until someone actually tests this out in a live environment we won't know for sure.

Should we create a PaymentIntent as soon as we show the subscription form?

No this is handled for you when creating a new subscription with the Stripe API. We need the setup intent to make sure you don't get asked for 3D Secure confirmations every time on your recurring billing.

I really don't think it's necessary to change anything on the current flow. We'll need confirmation of this happening on a live environment or someone from Stripe confirming before we make changes.

[albofish]

I'm battling the same issue.

From reading the Stripe documentation on this page they specifically state:

The Payment Intents API allows you to save cards after charging customers. This flow is great for businesses that subscribe customers to a monthly subscription or allow saving cards for future purchases

Whereas the Setup Intents:

Use the Setup Intents API to authenticate a customer’s card without making an initial payment. This flow works best for businesses that want to onboard customers without charging them right away

This suggests that depending on how Cashier is being used depends on which Intent fits. SetupIntent makes sense for trial accounts which will charge at a future date whereas PaymentIntents work for the scenario where the user is charged their first payment as soon as card details are given which sounds like the scenario @marcbelletre and I are trying to implement.

[hanspagel]

I'm seeing the same behaviour that @albofish is pointing out. Works for users that create a subscription during trial (with keeping their trial and being charged later) and has to be authorized two times when creating a subscription without a trial period.

We're not yet on production though.

[driesvints]

Have any of you actually tested this on a real production app yet? Because I still believe you won't get the second action requirement when you try to subscribe with a card that was set up using the setup intent token.

[driesvints]

Btw, nothing is stopping you from using a different flow. You could use the different flow there but if you don't use the setup intent token then I suspect you'll run into issue later when you customer is prompted for secondary payment actions when recurring billing occurs.

[TitasGailius]

I can reproduce the exact same issue.

It looks like the root cause of it is using Setup Intent because it still requires authentication when you want to perform an actual charge.

Use the Setup Intents API when you want to collect card details upfront, but you’re not sure when or how much you intend to charge the customer in the future. Common scenarios include:

• Saving payment methods to a wallet to streamline future checkout experiences
• Reserving the ability to collect surcharges after fulfilling a service
• Starting a free trial for a variable-amount subscription

While on the other hand Payment Intents looks like just the right thing when you need to perform a charge right away without giving a free trial:

Use the Payment Intents API to charge a card and save the details for future payments. Common scenarios include:

• Charging a customer for an e-commerce order and storing the details for future purchases
• Saving a card when a customer creates an account with your service, even if you’re not sure whether they will make another payment in the future
• Initiating the first payment of a series of recurring payments

So what I did is instead of creating a Setup Intent, I created a Payment Intent and used handleCardPayment in my javascript and it all worked out just as I expected.

[driesvints]

@TitasGailius you'll run into problems when you swap plans I think. Then again it should throw the incomplete payment exception in that case. I'll try to investigate this a bit more soon.

[ChiaraIT]

I'm facing the same problem. I'm using the Payment Intents API to charge a card immediately and saving the details for future payments, but I have to insert credit card data twice. Thank you in advantage for any further info. :)

[losa90]

Hi! I have the same issue. When the user has no trial period I create a PaymentIntent, then I go throw the handleCardPayment on js that prompts the 3d secure, but when I create a new subscription the IncompletePayment exception is thrown and the user must insert the credit card data again.
That is a big issue because the user can use a different credit card, so the first charge will be performed with the last created card but the future charges will be performed with the first payment method collected.

[selfcatering]

Guys just to help you out. Current implementation takes elements as a second argument. Unless there's no payment method attached to payment intent this is not correct. Again if there's a payment method call no-element handleCardPayment, reference https://stripe.com/docs/stripe-js/reference#stripe-handle-card-payment-no-element

[rocramer]

I have exactly the same issues as you @marcbelletre.

[derfysz]

Same here. After providing card details and on submission handleCardSetup is prompting for 3DS.

form.addEventListener('submit', async event => {
    event.preventDefault();
    ...
    stripe.handleCardSetup(
        clientSecret, cardElement, {
        payment_method_data: {
            billing_details: {
                ...
            }
        }
    }).then( function(result) {
        handleSetupIntent(result)
    });
});

function handleSetupIntent(result) {
    const {setupIntent, error} = result;
    if (error) {
        ...
    } else if (setupIntent) {
        var form = document.getElementById('payment-form');
        var hiddenInput = document.createElement('input');
        hiddenInput.setAttribute('type', 'hidden');
        hiddenInput.setAttribute('name', 'setupIntent');
        hiddenInput.setAttribute('value', setupIntent.payment_method);
        form.appendChild(hiddenInput);
        form.submit();
   }
}

Then form gets submitted. New subscription is created using setupIntent.payment_method, it throws IncompletePayment $exception and redirects to 'cashier.payment' asking for name, card and 3DS once again.

try {
    $subscription = $user->newSubscription('pro')->create(request()->setupIntent, $user_data);
} catch (IncompletePayment $exception) {
    return redirect()->route('cashier.payment', [$exception->payment->id, 'redirect' => route('home')]);
}

All webhooks are properly set up and working, $user->createSetupIntent(); passed to view with payment form to get client_secret.

Battling with this since few days. Would be grateful for help. As @driesvints asked - did anyone tried it on a live environment?

[driesvints]

As I said before: note that you're all testing with a card number that's specifically meant to always throw the 3D Secure error. That's why I'm asking to actually try this on a live environment.

[losa90]

@driesvints Actually Stripe provides these two credit cards specifically to test 2 different behaviours:

4000002500003155 (Authentication required on setup or first transaction) This test card requires authentication for one-time payments. However, if you set up this card using the Setup Intents API and use the saved card for subsequent payments, no further authentication is needed.
4000002760003184 (Authentication required) This test card requires authentication on all transactions.

Unfortunately both cards have the same behaviour!
I'm expecting double 3DS using the second credit card (because is required on all transactions), but the first one is not meant to always throw 3DS so I'm expecting 3DS just with the setupIntent

[driesvints]

@losa90 aha, that's good to know. Thanks for verifying that. I'm a bit out of time today but I'll allocate some time to look into this tomorrow.

[maximesahagian]

Hello,

I've tried to implement the new Cashier version, and I have the same issue as @marcbelletre, did you find a way to be sure that users in live version won't have to fill the card informations twice @driesvints ?

Thanks!

[driesvints]

No not yet. Sorry people, I'm a bit swamped with Laracon and all this week. If anyone can help figuring a better way for this code or docs wise than that's much appreciated.

[matusferko]

I have the same issue.

[SlyDave]

For what it might be worth. I have this occurring when a trial period of a product ends.

Setting up the payment Intent then using stripe.js v3 (elements) with card 4000002500003155 (ask on first, but not after)

The subscription creates just fine, but when the Trial period comes to an end, it then triggers 3DS - because it is off-session. an email should be sent out by stripe (if configured to do so in the Stripe Dasboard) -- The email does not get sent

Further to this, Ending the trial via the Stripe Dashboard doesn't work. The Stripe dasbhoard returning 'subscription_payment_intent_requires_action' when talking to it's own API - I have opened a ticket with Stripe about this.

If I attempt this with a product without a trial on it, it creates the subscription but fails to take payment ('subscription_payment_intent_requires_action' as as everyone else is experiencing, and the stripe_status is 'incomplete')

So I'm not sure how much of this is Cashiers fault... It's almost as if the 3DS trigged by handleCardSetup() isn't acknowledge by subsequent API calls, despite passing in result.setupIntent.payment_method into the create subscription...

[TitasGailius]

It feels like creating a SetupIntent means something like "I authorize you to collect my card details" while PaymentIntent is "I authorize you to charge my card for X amount".

I might be completely wrong because it's just a random guess based on intuition 😅

[losa90]

FYI today stripe is going to have a livestream on youtube about saving and reusing cards with SCA. The livestream starts at 3pm GMT.
Here's the link to the event: https://stripe.events/developer-office-hours-08-28
I think it might be helpful to those who is struggling with this issue

[SlyDave]

Just to clear up any possible confusion created by @TitasGailius 's comment about the differences between SetupIntent and PaymentIntent

PaymentIntent is used when intending to take immediate payment (on-session) and not save the card details to a Customer. Stripe automatically handles SCA if you use handleCardPayment()

SetupIntent is used when saving the card details to a Customer for later use (on or off session) - such as for payment of a subscription or after a trial period. or to simply store the details to short-cut the process for future purchases.

For a SetupIntent, Stripe automatically handles the creation of a mandate to allow future processing, (although you should update your legals and terms). They also automatically apply for exemptions for future SCA checks, however that doesn't mean they will be granted. Stripe automatically handles the initial SCA if you use handleCardSetup() (you can also use Cashier to handle it, see the docs)

For off-session SCA you either need to listen to the webhooks and get the user back on session to get them to complete the SCA check, or configure Stripe via your Stripe Dashboard to send your Customer an email on your behalf and Stripe will complete the SCA check.

At least that is how it should work, The SetupIntent work flow doesn't seem to be working for those in this thread (myself included). The initial SCA check is still occurs and works, but then the attempt to take payment triggers SCA again. -- this seems to be a Stripe issue. but could be an issue with how the Intent is setup via Cashier.. ?

[selfcatering]

You can definitely save payment methods with both. The difference is just the flow. With PaymentIntent you charge and might want to save a payment method. With SetupIntent it's the other way around: you save it but might charge it at a later stage. You can optimise PaymentIntent for off-session payments as well.

[ghost]

After the "Confirm Authorize Screen" am getting the error

"message": "The payment attempt failed because additional action is required before it can be completed.",
"exception": "Laravel\\Cashier\\Exceptions\\PaymentActionRequired",

Function used to trigger subscription is below

$user->newSubscription('main', $plan->stripe_plan)->withMetadata(['kroit' => $kroit])->create($request->stripePaymentMethod);

It's getting created as an Incomplete subscription.

JS side

    this.stripe.handleCardSetup(this.clientSecret, this.card, {
        payment_method_data: {
            billing_details: {name: cardHolderName.value}
        }
    }).then(function (result) {
        if (result.error) {
            self.cardError = result.error.message;
        } else {
            console.log(result);
            self.handleSubscription(result.setupIntent.payment_method);
        }
    });

The card is "4000002500003155" - Soecificaly 3D secure required and it's asking for confirmation

[SlyDave]

From the Developer Office Hours: Saving and Reusing Cards (SCA) Stripe YouTube Live Stream:

David Gray -- ​Is it to be expected that when using the 3155 card for a subscription that on first payment it asks for 3DS auth again? even when it was done on the initial handleCardSetup call?

Matus F
​Please could you try with 4000002500003155 so we can see that we dont need authentication again?

Marc Bellêtre
​@david Gray same issue here if I create a subscription with SetupIntent I have to confirm with 3D secure twice

Karl Reid [Stripe]
​@david Gray The exemptions from the SetupIntent only apply to off session payments — subscription creation is on-session by default, but you can pass a parameter to change that!

[marcbelletre]

@SlyDave I just saw this as well. I think we have to add off_session => true to the array in SubscriptionBuilder@buildPayload. I'm trying this out right now.
I don't understand why a subscription would be charged on session by default though...

[SlyDave]

Yeah, Agreed, it's a bit odd. if we used PaymentIntent I'd expect that to be on-session by default, but if we use SetupIntent I would expect that to be off-session by default. and as we're extremely likely to use SetupIntent with a subscription (as Cashier expects)... alas Stripe defaults everything to on-session, so Cashier will need to tell it to use off-session as per your suggestion! :)

[marcbelletre]

Okay guys I just tested setting off_session to true and this is working! I'm creating a PR right now for this.

[SlyDave]

I can confirm what @marcbelletre says -- adding off_session => true to buildPayload fixes the issue.
I'll leave the PR to Marc as he's already on it :)

[SlyDave]

Should also note that with the change applied and Stripe configured to send out emails for off-session authentication, Stripe actually does send the email now, and their hosted work flow for authing the payment works as expected. -- which it wasn't doing before (so one assumes they only do this if the PaymentIntent they auto generate is generated from a SetupIntent is configured as off-session to begin with)

[matusferko]

OMG! A needle in a haystack would be easier to find.

[TitasGailius]

Tested it as well, it works. Great job figuring this out!

[ghost]

Add 'off_session' => true, into subscription buildPayload when using stripe.handleCardSetup()

[matusferko]

Actually isnt that a stripe api bug?
Setup intent was created with 'off_session' true (for future off session usage) and associated payment method was used in subscription creation as default_payment_metdho parameter.
What do you think?

[SlyDave]

The setup intent was flagged as off session and was handled as off session. The subscription wasn't flagged as off session and so wasn't handled as off session. They're two independent calls to the stripe api. As counter intuitive as that might seem.

[driesvints]

Hey everyone. As so many people reported the issue as fixed because of the change I'm closing this. Thanks to everyone helped figuring this out. I'll be tagging a new release in a few moments.