#timothyshaw-applepay-save

1 messages ยท Page 1 of 1 (latest)

warped pagodaBOT
vital fox
#

Our case is that we currently have users with a credit card payment method on file for later use, added with setup intent. We are able to create payment intents at any time for the user. Our app has users taking rides, so there is a payment intent for the ride that start when ride begins and we capture when the ride ends. After the ride, the user can tip their driver which we have implemented as a second, new payment intent.

We want to implement Apple Pay as a payment method and understand how to integrate, but we need clarity on whether the payment method we get from Apple Pay can be reused any more than 1 time. For example, it would be helpful if we only needed to show the Apple Pay payment sheet one time at the beginning of the ride, get the payment method, and use that for the ride payment AND reuse it for a second payment intent after the ride is over for the tip.

It would be even more useful if we could reuse that payment method further into the future as well but understand there may be some limitations?

Would it work to reuse the payment method from Apple Pay perhaps an hour or 2 after the first payment intent it was retrieved from, without needing to have the user confirm again via the Apple Pay sheet? And if it is possible, are there any risks with reusing that payment method for additional payment intents?

#

i think the conflicting answers we've gotten are either "apple pay can be used just like a credit card" vs "you must show the apple pay sheet to the user for every payment intent"

unique anchor
#

timothyshaw-applepay-save

#

@vital fox so just to understand, you say you came here multiple times, asked that question, got different answers maybe, and now are asking again?

vital fox
#

yes

unique anchor
#

๐Ÿ˜…

vital fox
#

haha

unique anchor
#

didn't expect a yes to that question

vital fox
#

i could find the past threads if helpful

unique anchor
#

no I'm good lol

#

On Stripe, when accepting a payment via Apple Pay, it creates a "normal" card PaymentMethod. That can be attached to a Customer and re-used for future payments, there's no technical difference in the API between the two.
Now Apple (and Google) have their own strict rules around what you can and can not do with Apple Pay. If a Customer is on your website buying something, you are not allowed to re-use the previously saved PaymentMethod from a previous Apple Pay transaction. You have to present the Apple Pay UI each time to the customer. If you have used Uber or Lyft for example in the US, that's exactly what they do each time.

But for "off session" payments, where the Customer is not on your app/website, it's different. Apple (and Google) do allow recurring payments and similar where you tell your Customer they are going to be charged later (whether it's a true subscription recurring on the same date or not, like incidentals for an hotel reservation). In that case, it's allowed to charge their saved PaymentMethod. But you might get real declines (like any card payment)

vital fox
#

Ok interesting. So if they are within the app and initiating some transaction, be it paying for a ride, paying for a tip, etc, that sounds like "in session" and the intention from Apple is to present the apple pay UI.

#

the incidentals piece is good to know about because there can be incident charges depending on if anything crazy happens during the ride (rare but possible, like vomiting in a car or otherwise damaging vehicle).

#

How does Apple know whether it's an in session vs off session? or how does it know the apple pay UI was shown to the user for a payment intent or not ๐Ÿค”

unique anchor
#

It's part of the transaction. When you show the UI, we get some custom value (a cryptogram) and use that. So Apple (and the banks) know what is happening.
Overall, don't try and game the system, and show the UI every time you customer is buying something on your app/website

vital fox
#

Got it. One more follow up question -- one reason we have ride payment vs tip payment as separate payment intents is our understanding that Stripe does not allow a payment intent amount to be increased once confirmed. We do have some padding on the amount already to account for some fees, but to allow for tips which can sometimes be a lot, it seems like we would need to have a high amount of padding that could seem suspect to the user when we present that amount.

Not sure if these rules around payment intent are different at all if Apple Pay is the payment method.

For example I know that Lyft and Uber end up having a single charge that covers the ride and tip, but that seems like it would need the amount to be able to get increased.

pallid quarry
#

๐Ÿ‘‹ stepping in as Koopajah needed to step away

#

Yeah overall two PaymentIntents is likely what you want here. Otherwise, you can use auth & capture to authorize a higher amount and then only capture the amount needed. However, as you noted, this could lead to customer confusion.

vital fox
#

Right. I just don't personally recall having a very high padded initial amount (e.g. to cover tip later), and don't recall needing to confirm payment a second time when tipping. On platforms like lyft / uber. Wondering if Apple has separate rules?

Like "a payment intent amount can't be increased", is this a Stripe API rule vs an Apple rule perhaps.

pallid quarry
#

These aren't rules really. It is about features

#

We don't have anything public that allows you to increase your authorization amount on a confirmed PaymentIntent. You can reach out to our Support team and ask if there is anything like that which your account might be eligible for.

vital fox
#

Ok. Yes we can ask about that. We understand that Stripe could also possibly be used as a payment processor for a native apple pay integration? Rather than through Stripe SDK. Do you know if that is true.

pallid quarry
#

Yes that is true

vital fox
#

is that covered anywhere in Stripe documentation?

pallid quarry
#

No it isn't really. What you do is you create a Stripe Token from an Apple Pay Token, so basically an example cURL request would look like: curl -u sk_test_123: https://api.stripe.com/v1/tokens \ -d pk_token=<PKPaymentToken.paymentData decoded as JSON> \ -d pk_token_instrument_name=<PKPaymentToken.paymentInstrumentName> \ -d pk_token_payment_network=<PKPaymentToken.paymentNetwork> \ -d pk_token_transaction_id=<PKPaymentToken.transactionIdentifier>

vital fox
#

ok. but we could probably find apple documentation on it and it would involve something with this token creation

#

ok. i think that's all for now. Thank you both, it's been very helpful.

pallid quarry
#

Happy to help!