#jordan-apple-setup

1 messages · Page 1 of 1 (latest)

proud hare
sullen plume
#

It pertains that on iOS we are using PaymentSheet.FlowController for normal CCs, and we have a dedicated Apple Pay button so the docs recommend that we do this:
"If your checkout screen has a dedicated Apple Pay button, follow the Apple Pay guide and use ApplePayContext to collect payment from your Apple Pay button. You can use PaymentSheet to handle other payment method types."

#

In the Charges world we are actually saving Apple Pay cards to a Customer as payment methods and these are sometimes charged again because this becomes the user's preferred payment method. These future charges succeed, but I understand that this is a no-no and we'd like to stop doing this in the future

proud hare
#

Hi there, thank you very much for the information, please allow me to read through and understand your use case

sullen plume
#

Hi Makoto- thanks for the reply

#

If it helps, I've been looking at this SetupIntents doc:
https://stripe.com/docs/payments/save-and-reuse?platform=ios&ui=payment-sheet#apple-pay
which directed me to this doc:
https://stripe.com/docs/apple-pay#present-payment-sheet
But that second doc doesn't exactly mention what we should do in our case, as it covers an immediate payment at time-of-checkout

Set up future payments

Learn how to save card details and charge your customers later.

Apple Pay

Allow customers to securely make payments using Apple Pay on their iPhone, iPad, and Apple Watch.

proud hare
#

Sorry, I am currently testing to see if SetupIntent would work with your PaymentRequestButton implementation 🙂

sullen plume
#

Okay- thanks a bunch

#

PaymentRequestButton is just for web though, correct? We have a button that we style ourselves as an Apple Pay button, and that triggers the presentation of the Apple Pay sheet

#

At the moment, we aren't using the Stripe SDK to handle the presentation of the Apple Pay sheet (we use PassKit directly), but we were planning on migrating to the Stripe SDK method of doing so (listed in the second doc above). Does that make sense?

hexed lintel
#

Hi @sullen plume I'm Jack and I'm also an engineer from Stripe. You mentioned that you are using PassKit, so are you looking for solution to convert the Apple Pay token to Stripe token to minimize the changes to your iOS app?

sullen plume
#

I'm mostly just a bit confused as to how we should be creating SetupIntents with a Apple Pay and how we should be creating single-use tokens mentioned in the docs

hexed lintel
#

OK, so can you tell me your use case here? Are you going to have a subscription for recurring payments?

sullen plume
#

As I mentioned above, we don't want to issue a charge to a user's Apple Pay card at point-of-checkout, but we also don't want to permanently save this token to a customer object

#

No, we don't have subscriptions and all of our charges are one-off. It's just that we want to charge their cards offline

hexed lintel
#

So in another word, you can't do off_session payment with Apple Pay for non-subscription payments.

sullen plume
#

Yeah I have read that before. "can result in it being declined" -> we are currently using the Charges API in prod and we are actually seeing that we can still charge a card that was originally created via Apple Pay multiple times

hexed lintel
#

Can you share me the charge ID so I can take a look?

sullen plume
#

We are currently doing off_session payments with Apple Pay via the Charges API - are you positive that this is true?

#

Let me dig one up

#

This should be an example of one: ch_3KBOGx2aMfcdR0nn1Wecq4sP

#

These are a bit tough to look up in the dashboard

#

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

#

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.

hexed lintel
#

Yup, this card was created before the charge. Do you use the card for payments more than one time?

sullen plume
#

Yes multiple times, but I'm not sure when it was created exactly

#

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

#

In this case, the user was checking out via our iOS app, but I'm not sure if this is the point at which the Apple Pay card was created (this user has purchased from us 17 times in total, so it's likely that it was created before this charge)

#

Here's another charge from the same customer, but he is using a different card on Sep 29, 2021: ch_3Jf9ul2aMfcdR0nn0PHakqSo

#

So I think it's likely that the ch_3KB8rv2aMfcdR0nn078Q8Uv5 charge was the first creation of that Apple Pay card

hexed lintel
#

Hi @sullen plume 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.

sullen plume
#

Right, that was my take-away as well. So it's observationally the case for us that we actually currently aren't seeing these charges being declined. But we also understand that this isn't best practice for Apple Pay and we would like to migrate away from saving Apple Pay cards to customers like this.

So in the SetupIntent world, how might we create Apple Pay cards, charge them once, and not have them show up in a user's list of permanent payment methods?

hexed lintel
#

The purpose of SetupIntent is to store the payment details of the customers, so once the SetupIntent is confirmed successfully, the associated payment method will be shown in the customer's list of payment methods.

May I know why do you want to hide it?

sullen plume
#

Both Apple and Stripe recommend that we don't save a user's Apple Pay card for one-off charges unless it should be used for a subscription. So we want to stop doing this, but we also need to be able to issue a charge slightly later after checkout when we actually start manufacturing clothes for a given user's order

#

In normal cases charges get issued only a few hours later, but it depends on the bandwidth from our factory. So it can vary a bit, but the charges do get issued offline and we don't take payment at time-of-checkout

#

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

#

I would like to know how to do this, and also issue a charge post-checkout for a given card created with Apple Pay

hexed lintel
#

I see, so in that case, can I suggest to use manual capture with PaymentIntent?

#

It allows you to manually capture the payment up to 7 days.

sullen plume
#

Btw, I was directed there from here:
If your checkout screen has a dedicated Apple Pay button, follow the Apple Pay guide and use ApplePayContext to collect payment from your Apple Pay button. You can use PaymentSheet to handle other payment method types.

hexed lintel
#

So in Step 7, when you create the PaymentIntent, you can pass in a capture_method = 'manual;

sullen plume
hexed lintel
sullen plume
#

Ah, okay so when we call our endpoint to create a PaymentIntent we would set capture_method = 'manual but only for Apple Pay payments

hexed lintel
#

It's not only for Apple Pay, you can use this capture_method for card as well.

sullen plume
#

And we would use SetupIntents on the iOS client for all other normal CCs?

hexed lintel
#

Yup, you can use SetupIntent for credit cards.

sullen plume
#

Ah, I should clarify- for other CCs, we would be creating SetupIntents on the iOS client and then our backend would be creating PaymentIntents when we need to charge that card (so in that case we would just want to charge those cards immediately)

hexed lintel
#

So to summarise

  • You can use SetupIntent for normal credit cards and charge the customers later
  • You can use PaymentIntent with capture_method=manual for Apple Pay card, and charge the customer one time only within 7 days
sullen plume
#

Okay that makes sense to me

hexed lintel
#

Cool. 🙂

sullen plume
#

So for Apple Pay cards for which we have created a PaymentIntent, would these show up in the PaymentSheet as payment options then? My guess is no?

#

If so, that is exactly the behavior that we want (a user shouldn't see or be able to select an Apple Pay card that was set up previously when they return to the checkout page)

hexed lintel
#

It won't. The PaymentSheet will displayed the regular payment methods that are attached to the customer. the payment_method set up from capture_method=manual paymentIntent is like a 'one-off' payment and it won't join the list.

sullen plume
#

Perfect

#

Thanks Jack- this has been super helpful, so I really appreciate you taking the time to help us out here!

hexed lintel
#

Happy to help! Feel free to reach out to us if you have any other questions 🙂