LEO LIU

[iron adder]

Hello! What's the Q?

[hidden harness]

hi there

if our downstream customer wanna pay via Apple Pay, according to my previous understanding

every time the customer pays via Apple Pay, we must retrieve a new PaymentMethodID from Stripe's SDK, even if it's the same card

then we attach that PaymentMethodID to the customerID assigned by Stripe, and invoke Create PaymentIntent API to complete the payment

our system now actually applies above code

the question is why we need to retrieve a new PaymentMethodID and attach it to the customer every time paying via Apple Pay? I've heard this is to meet Apple's compliance requirements, is it true?

[iron adder]

Sure, this seems expected if they're initialising a new Apple Pay session for each payment

[hidden harness]

if we are able to differentiate if it's the same card, can we just pass the previous PaymentMethodID to Stripe instead of retrieving a new one while creating PaymentIntent?

[iron adder]

Exactly!

[hidden harness]

So this solution is actually doable? and wont cause any compliance related issue?

and also wanna hear more insight from you, like is it a general practice for Apple Pay integration

[iron adder]

Reusing a pm_xxx object? No, that's their whole purpose

[hidden harness]

so retrieving a new PaymentMethodID every time paying via Apple Pay is required by Apple?

[iron adder]

No, they're usable. This is how it works:

• Apple Pay sheet is presented.
• Customer selects payment details from the wallet.
• We tokenise that data (into a pm_xxx object), that can be re-used if correctly configured

Can you share an example pi_xxx?

[iron adder]

Rather than you sharing the Apple Pay display to them each time (which will just created a new pm_xxx object), you will re-use the previous pm_xxx saved on the Customer object

[hidden harness]

oh that's great

[hidden harness]

May I know is it the general practice? that re-use the Apple Pay pm_xxx?

[iron adder]

Depends, if they're ad-hoc one-time payments then the recommendation is to not re-use them: https://stripe.com/docs/apple-pay?platform=web#recurring-payments

[hidden harness]

as what it states in Recurring payments section

attempting to reuse payment information for a non-subscription payment can result in it being declined.

[iron adder]

Which is what I just said above:

[hidden harness]

how can Stripe tell if it's a subscription payment or non-subsrtiption payment?

and could you advise how the response payload of Create PaymentIntent API looks like if the payment get declined?

we're a BNPL service provider, which means our downstream customer will only pay the downpayment or first bill via Apple Pay. Then we save the PaymentMethodID we just retrieve, and use it for subsequent bills money collection, and it all goes well now

[iron adder]

There's markings according to how we generated the Payment Intent

[hidden harness]

and we're wondering, if next time customer places a new order, can we still reuse the PaymentMethodID, just like what we did while collecting subsequent bills

[iron adder]

It depends on the reason for decline, you should test this. But generally requires_payment_method: https://stripe.com/docs/payments/intents

[iron adder]

As explained, yes. But it's likely to be declined if its an Apple Pay generated payment method