#Jordan.Knapp-apple-pay-qs

1 messages Ā· Page 1 of 1 (latest)

woeful snow
#

Hello šŸ‘‹

chilly linden
#

Hey hanzo- thanks for your reply! Give me a bit to collect my questions and I'll post them here

woeful snow
#

Sure!

chilly linden
#

We are currently migrating from Charges to SetupIntents. As a part of our internal order creation process, we need to attach a card_/pm_ id to an order to be charged offline later when we actually start the fulfillment process. We don't charge our customers immediately upon checkout, and only when we start manufacturing their order. The period between when a customer checks out to when we actually start manufacturing/fulfilling their order can vary, but in some cases it can take >7 days (our factory may have delays, a customer submitted a bad measurement video and they take forever to respond to us, etc).

So, for normal credit cards this is no problem- we just create a SetupIntent to store their card upon checkout, and then we can create a PaymentIntent later on our backend when we want to start manufacturing their order. But for Apple Pay this presents some issues. We have a recommendation to use capture_method = manual (the context for this is the #jordan-apple-setup thread in #dev-help). But we know that a confirmed PaymentIntent with capture_method = manual will result in the PaymentIntent getting automatically cancelled after 7 days.

#

We have a proposed solution, and I wanted to see if this would work. Instead of setting capture_method = manual for an Apple Pay PaymentIntent, we would do confirmation_method = manual instead, with capture_method = automatic by default. This seems to work on the client-side in terms of using the PaymentIntent that was created within the Stripe/Apple Pay sheet delegate callbacks (we get a "success" result on the client). So for this PaymentIntent, can our server then confirm/charge it later even if it has been longer than 7 days since the creation of the PaymentIntent?

woeful snow
#

I need to head out but@mystic token will be able to help you! šŸ™‚

chilly linden
#

Okay sounds good

mystic token
#

Hi šŸ‘‹

#

This is a pretty involved question so I'm discussing it with my colleagues to try and get you a solid answer

chilly linden
#

Okay thanks for your help. It might be helpful to read some of the context in the #jordan-apple-setup thread, but I'm mostly interested in the confirmation_method = manual status on a PaymentIntent and what it might mean if we try to confirm/capture this payment via our backend in a >7 day scenario

mystic token
#

Okay so let's step back. All payments captured for later use with a Payment Intent will only work up to 7 days.

chilly linden
#

Correct- at least that is my reading of your docs

mystic token
#

So lets start with why you want to do something different with Apple Pay

#

Since SetupIntents work so well with cards

chilly linden
#

We don't want to create a SetupIntent for an Apple Pay card moving forward, as that is against the ToS of Apple Pay and Stripe for one-off payments (not subscriptions). We are currently saving cards created via Apple Pay for one-off payments to our Stripe Customer objects in the Charges API world, but we realize that this is a no-no, and we'd like to move away from this. Hence the motivation to create a PaymentIntent for a given purchase.

It's just that in our case we don't plan on charging those Apple Pay cards immediately, and it may take >7 days for us to actually start manufacturing a customer's order. So we don't want those specific customers to have to come back and re-enter a card, as that would affect a big part of our revenue

mystic token
#

We don't want to create a SetupIntent for an Apple Pay card moving forward, as that is against the ToS of Apple Pay and Stripe for one-off payments (not subscriptions).

#

I'm curious where this is located in the docs. I cannot find any reference to it

chilly linden
#

I referenced it in the #jordan-apple-setup thread, but I can dig it up. Also, apart from the Stripe docs/recommendations around Apple Pay, it seems to be not what we should do with these cards according to Apple directly.

#

You can use Apple Pay tokens to create one-off payments or subscriptions. For repeat purchases that arenā€™t related to a subscription, Stripe recommends that you create single-use tokens. Your customer must authenticate with the Apple Pay payment sheet each timeā€”attempting to reuse payment information for a non-subscription payment can result in it being declined.

mystic token
#

Right but as you describe your scenario these are one-off payments. You are not using them for recurring changes.

chilly linden
#

Correct, which is why we shouldn't save them to a Stripe Customer object moving forward

#

We are currently doing this in the Charges API world, and we haven't faced issues with issuing future payments to a returning customer's Apple Pay-created card in production (see the #jordan-apple-setup for verification of this)

mystic token
#

But I can understand that desire to move into the SetupIntent /Payment Intent world

#

Okay I confirmed with my colleagues. There is no problem using SetupIntens as long as that specific payment method is used only once

#

ApplePay doesn't have a problem with it as long as there is a 1:1 ratio of approval through a paymentSheet and a transaction

#

A SetupIntent in this case is viewed as a single payment occurring at a later date

chilly linden
#

Okay so as to my original question here:

We have a proposed solution, and I wanted to see if this would work. Instead of setting capture_method = manual for an Apple Pay PaymentIntent, we would do confirmation_method = manual instead, with capture_method = automatic by default. This seems to work on the client-side in terms of using the PaymentIntent that was created within the Stripe/Apple Pay sheet delegate callbacks (we get a "success" result on the client). So for this PaymentIntent, can our server then confirm/charge it later even if it has been longer than 7 days since the creation of the PaymentIntent?

Would this not be a working solution with PaymentIntents?

mystic token
#

This would not work. PaymentIntents would still fail after 7 days

#

That's a function of the PaymentIntent that is not configurable when making the request to the API

chilly linden
#

That doesn't seem to be true, as it is referenced explicitly in the docs. Our backend endpoint that creates these Apple Pay PaymentIntents just adds confirmation_method = manual as an option and what is given back seems to work on the client with Apple Pay

#

My concern with using SetupIntents for one-off Apple Pay transactions in this case is that we 1) would have to manually detach these from the Customer object after fulfillment, and 2) those would show up in the Stripe PaymentSheet as payment_methods in the interim between step 1)

mystic token
#

In this case you may run into declines with card issuers

chilly linden
#

Right, those docs seem to be for capture_method = manual. I'm asking about confirmation_method = manual and if that would be a workaround here for the >7 day window

#

We've already verified through testing that PaymentIntents created with confirmation_method = manual will satisfy Stripe's delegate callbacks for the Apple Pay sheet. I'm just asking if we can rely on the manual confirm of that PaymentIntent on our server later to charge that PaymentIntent's pm_ outside of the >7 day window

mystic token
#

And I am telling you I would not depend on this for payments later than 7 days. I realize this is not ideal with ApplePay's peculiarities but making payments later is the explicit purpose of SetupIntents.

chilly linden
#

I understand, but this already works for us in the Charges API world in production. So if my proposed solution won't work involving PaymentIntents w/ confirmation_method = manual, my fallback would be to do exactly what we are doing now (using PassKit directly to manage presentation/transaction of the Apple Pay sheet, tokenizing this card via Stripe, then charging it later). The only difference would be that we won't be saving this card to their Stripe Customer object

#

We are in some sense "fine" with not relying on payments succeeding later, but I would like to know if this restriction is a Stripe hard-restriction with PaymentIntents w/ confirmation_method = manual, or if it's just that "these might be declined" which is what we face now in production (but in reality none of these payments get declined- we are still able to charge an Apple Pay card that has been saved to a user's Customer object)

mystic token
#

The attempt will likely fail and it isn't something we advise. If you have managed to do this we would be interested in a charge ID so we could review the card issuer response.

chilly linden
#

These are a bit tough to lookup from the Stripe dashboard, but here is one:
ch_3KBOGx2aMfcdR0nn1Wecq4sP

#

The card_tokenization_method for the payment method that was used for this charge is apple_pay, but this user created this card via Apple Pay at some earlier date. The card got saved to the customer as their preferred payment method, and then created this charge on Dec 27th, 2021. Our analytics tell us that the user was actually on a Windows computer shopping via desktop browser, but the charge succeeded

#

Here's an example of us charging the same card two days before for a separate purchase: ch_3KB8rv2aMfcdR0nn078Q8Uv5

#

These charges are just the ones I looked up from the #jordan-apple-setup thread originally, but there are many other examples

#

Your colleague said this in response to those charges:

Jack Tan ā€” 01/06/2022
Hi @chilly linden thanks for the waiting, and I just verified that this card has been used for multiple payments.
My previous answer was too definite, I read the doc again, and it says reuse payment information for a non-subscription payment can result in it being declined., So it means that there's a possibility that the charge can go through, but not guarantee.

mystic token
#

In regards to which scenario? Apple Pay?

chilly linden
#

Yep, any charge I would put here are for cards originally tokenized via Apple Pay

#

And we have no perceived issues with re-charging those cards currently saved to a Customer- they all succeed even though they aren't a part of a subscription

mystic token
#

As Charges? None of them are using SetupIntent or PaymentIntent?

chilly linden
#

Right- we are making our best effort to migrate to the Intents API for Apple Pay, but we are currently using the Charges API in production

#

I haven't heard of a possible workaround for the >7 day Apple Pay scenario from Stripe devs, so it seems like we just need to continue doing what we are doing now as a fallback for Apple Pay unless you can advise?

#

And it seems like my original proposed workaround here would take a while to test (create this PaymentIntent via Apple Pay with confirmation_method = manual and just wait to see if we can successfully charge it outside the 7 day window):

We have a proposed solution, and I wanted to see if this would work. Instead of setting capture_method = manual for an Apple Pay PaymentIntent, we would do confirmation_method = manual instead, with capture_method = automatic by default. This seems to work on the client-side in terms of using the PaymentIntent that was created within the Stripe/Apple Pay sheet delegate callbacks (we get a "success" result on the client). So for this PaymentIntent, can our server then confirm/charge it later even if it has been longer than 7 days since the creation of the PaymentIntent?

#

Do you have any methods for shorter testing feedback here?

mystic token
#

I still see that as much more risky and likely to fail compared to using SetupIntent objects and removing the payment method after the charge.

chilly linden
#

Okay- do you know of any ways to test this without waiting 7 days?

#

Also, keep in mind my concerns here:

My concern with using SetupIntents for one-off Apple Pay transactions in this case is that we 1) would have to manually detach these from the Customer object after fulfillment, and 2) those would show up in the Stripe PaymentSheet as payment_methods in the interim between step 1)

mystic token
#

I've got to step away but my esteemed colleague @true gazelle will be able to answer your questions.

chilly linden
#

Okay, but I hope that @true gazelle can understand the context here. Thanks for your investigation @mystic token !

marsh bramble
marsh bramble
#

I'm asking about confirmation_method = manual and if that would be a workaround here for the >7 day window
confirmation method really has nothing to do with capture method so they don't relate and it's not a workaround.