#stewartmcgown-react-SDK

1 messages · Page 1 of 1 (latest)

tight oak
chrome token
#

we're using react native 🙂

tight oak
#

Ah! Apologies for the oversight. Let me dig a bit

chrome token
#

this is our current setup w/ Tipsi

#

basically imperative calls to 1) open up apple pay setup 2) open apple pay sheet 3) complete the apple pay context when we get the token

then offscreen, call my backend and syncronously confirm the paymentintent using the provided token as payment

#

Okay - think i'm partly there with Apple Pay. Tipsi had an imperative method to open a card details collection screen that I could use to collect card payment methods via the Stripe in-ubilt PCI compliant tokenisation - not sure if that is something support by this SDK

little verge
#

I believe it's technically possible but a little obscure, since that whole "tokenize on the frontend and post to a backend to process the payment" flow is considered deprecated by us today.

Just to clarify one thing, do you only care about Apple Pay? Like what does your app do today if the device doesn't support it or has active cards? Sounds like you just don't let them pay?

chrome token
#

^^

little verge
#

oh tipsi has this withCardForm thing I suppose

chrome token
#

i will migrate to ur new flow when I can but fuck i'm losing customers left and right since tipsi no longer works

#

Ya, they have the paymentRequestWithCardForm that gives me a token

#

if it's gone then i may have to chomp down hard on the bullet and do things your way :p

little verge
#

honestly if it was me I would do the migration to https://stripe.com/docs/payments/accept-a-payment?platform=react-native&ui=payment-sheet now , it's much easier in the long run.

If you're stuck with the old approach then you can at least use CardForm https://stripe.dev/stripe-react-native/api-reference/index.html#CardForm and createToken : https://stripe.dev/stripe-react-native/api-reference/index.html#createToken

I haven't tried that in that configuration but it's one option that might work.

#

that doesn't support Apple Pay and I need to have a look if there are any options but I don't think there are, we explicitly simplified the Apple Pay integration last year so it relies on a PaymentIntent instead of giving you raw tokens.

#

ultimately if you're using the legacy approach you also have the problem of not supporting 3D Secure and SCA card authentication which is now fully rolled out in EU+UK so you really should try to use the current integration.

chrome token
#

i support sca just fine with my own callbacks

#

dw about that bit

little verge
chrome token
#

ahhhh

little verge
#

I really don't think there's any solution here that is not moving to PaymentIntents.

chrome token
#

so i must use a payment intent

#

bollocks

#

i need to confirm them on the server rn

#

i guess time to move away from sync

little verge
#

fair! they have been the default integration since 2019 though, but yeah, at some point you will have to migrate

chrome token
#

well i chose it for a reason, not for fun

#

my issue is in food delivery, we frequently must cancel payments soon after placing

#

because restaurant cant prepare food etc

little verge
#

you could auth-and-capture then and refund the auth(no Stripe fee for that, and reversals like that usually are fast to appear back on the customer's balance)?

chrome token
#

as long as i can still do the auth-capture with new async

#

then all good

#

ya

little verge
chrome token
#

how does this work then with my increase payment after the payment has been authorised flow, for tipping drivers after delivery? am I still able to do that without prompting additional payment verification?

little verge
#

well how do you do that today?

chrome token
#

Currently, because it's sync, my server can just call the paymentintent create API and confirm it without the user having to do anything

#

I assume I will need to essentially re-implement the checkout flow for adding a tip after delivery now?

little verge
#

I don't see why you would no, it would be the same

#

you'd have your app accept the card details and charge them, saving them during that payment

chrome token
little verge
#

your backend can later do a new off-session paymentintent for the tip to attempt to charge the customer's card

chrome token
#

I would probably need to ensure I charge their card first before i cancel their old, authorised intent

little verge
#

bit hard for me to say without deep diving into your current integration but most flows should be possible.
But overall the recommended approaches are to have the backend return a PaymentIntent to the frontend and have the frontend complete the payment information collection and processing the payment(using our PaymentSheet component which supports Apple Pay/cards/other payment methods). You can capture the payment later on the backend, or charge the saved card if you saved it during that initial payment.

chrome token
#

migration time it is