#aidan_best-practices

1 messages · Page 1 of 1 (latest)

near ginkgoBOT
#

đź‘‹ Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

đź”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1324419393404403742

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

mighty bone
#

Hi đź‘‹

It is up to your integration to determine whether to create a new Payment Method or re-use an existing one. How are you taking payments currently?

stray raptor
#

We’re taking payments using payment intents api, for regular credit cards we are reusing the existing payment method.

For Apple and Google pay it doesn’t seem like we can reuse the existing payment method since we need to revalidate the payment method and can not use a Google pay method on an Apple device

#

So instead we have just been creating a new payment method each time Apple or Google pay is used

mighty bone
#

When you save a Google/Apple Pay payment method, you are really saving the underlying Credit Card.

#

Now Apple can get very restrictive

#

They generally don't like merchants to use Apple Pay for payments where the customer is not on session

#

For Google Pay, you can just used the saved Card

stray raptor
#

Thanks for the link, we have already implemented off session handling for Apple and google pay.

For dealing with the duplicate payment methods it seems like some potential solutions are:

  1. Allow duplicate payment methods on BE but merge payment methods view on FE using the payment method fingerprint

  2. Pass existing Apple/Google pay payment method when creating stripe payment intent (doesn’t seem like this one would work due to cross platform issues I mentioned before)

Are there any simpler or stripe suggested solutions I’m missing here?

mighty bone
#

If you have saved payment methods set up for re-use, we recommend using the two step confirmation approach on your frontend https://docs.stripe.com/payments/build-a-two-step-confirmation . Then you send the data to your back-end and check the generated fingerprint before saving the new PM. If it's the same, just re-use the existing one instead.

stray raptor
#

Thank you! I will take a look at this and these docs

mighty bone
#

This Token object has all the data for the Payment Method before you actually save it

#

You send this token to your back-end where you can compare the fingerprint in the payment_method_preview.card.fingerprint property against other saved PMs for the same customer.

stray raptor
#

Thanks! One last question, let’s say I create a payment intent on an iPhone using Apple Pay, this adds a payment method to my stripe customer.

Can I then go on my windows laptop and choose this saved “Apple Pay” payment method token and use it for checkout?

mighty bone
#

That depends.

Did you save the payment method using the Apple Pay recurring approaches in the docs I linked above?

stray raptor
#

Yeah we are saving the payment method using payment or setup intent depending on value of transaction.

#

“Apple Pay terms forbid using a saved payment method for usage=on_session payments. If the customer is in the flow, you’re required to have them authorize and generate a new cryptogram for that transaction.”

#

Seems like the Apple terms would prohibit this though if customer is involved?

mighty bone
#

Okay so that means if the Customer is interfacing with your UI you have to create a new Apple Pay PM

#

Yeah, Apple is pretty strict with that stuff

stray raptor
#

Yeah they will be present and interfacing with the UI in some of these cases

#

Yeah unfortunately seems to be so

mighty bone
#

Okay yes, in that case, Apple Pay wants to go through their own authentication process for every transaction

stray raptor
#

Okay sounds good I think in our case then the best bet is to deduplicate payment methods on FE but leave them attached on BE

#

Since the confirmation token solution would still not deal with the Apple Pay edge case where they need to re authenticate with Apple and create a new cryptogram

mighty bone
#

Well you could flip it around, where you use the fingerprint to identify duplicates and you do save the new payment method and de-activate the old one.

#

That way, if you are charging the customer when they're off-session, you have the most up-to-date payment info

stray raptor
#

Yeah I was thinking of this too, we have a form of this solution in place in production today where we replace the payment tokens and it’s working but is quite over head intensive since we need to potentially update in a lot places and does pose some operational risk if we mess it up

#

But yeah seems like two possible solutions then are

  1. Deduplicate cards on FE using fingerprint
  2. Replace all cards with same fingerprint everywhere when new payment method is attached
mighty bone
#

For 2. Are you storing the PM ID in other locations?

stray raptor
#

Yeah we are storing the payment method token in our db so that we know which method to charge in future

mighty bone
#

Gotcha, makes sense. So there could be a race condition if you have some automatic payment triggered at the same time a customer saved a new payment method