Create PaymentMethod with Apple Pay

[trex-quo]

Is your feature request related to a problem? Please describe.
When creating a subscription for a customer with a debit card, it is clear and straightforward that the payment method is stored with the subscription and associated with the customer object. You can either create a PaymentMethod using the card information and associate it with the subscription in that manner, or you can pass in setupFutureUsage: 'OffSession' to confirmPayment() to associate the card information.

When paying with Apple Pay, it is not clear that the Apple Pay payment method is being associated with the subscription. I create a subscription on the server side and pass in payment_behavior: "default_incomplete", and then call confirmApplePayPayment() on the frontend. Do I just trust that the payment method will be associated and charged again when the customer's subscription auto-renews?

Describe the solution you'd like
Allow us to create Apple Pay tokens and create PaymentMethods with them, as noted by Stripe documentation here:
https://support.stripe.com/questions/using-apple-pay-for-recurring-payments

Or add a setupFutureUsage field to the confirmApplePayPayment() so that we can be sure that the customer's payment method is associated with their subscription.

Describe alternatives you've considered
Use confirmApplePayPayment() with a payment_intent secret from the server-side subscription object and hope that the payment associates itself.

Additional context
My main concern here is with changing payment methods on the customer's subscription if the customer has a subscription with no PaymentMethod attached to their customer object. What would happen if we called (server-side)

await stripeClient.subscriptions.update(stripeSubscriptionId, {
  payment_behavior: "default_incomplete",
});

for an Apple Pay payment whose payment_intent never gets confirmed on the frontend? In my mind, if this happened with a debit card payment, at least the associated PaymentMethod attached to the customer object would be a fallback method for payment, but would this wipe the Apple Pay payment method off of the subscription object?

[thorsten-stripe]

Thanks @trex-quo, we should provide a way to get the payment method from Apple Pay. We'll track this work here.

[trex-quo]

I think that a workaround for the time being would be to retrieve the PaymentIntent from the subscription immediately after creating it server-side, and then update the PaymentIntent with {setup_future_usage: 'off_session'} before returning the client_secret to the client. Does that sound reasonable?

Edit: I found a solution that works well for the time being (using Apple Pay as a payment method for subscriptions):
Server side

• For new subscriptions, create a subscription object using {payment_behavior: "default_incomplete"}. Grab the latest_invoice.payment_intent.client_secret off of the subscription and return it to the frontend
• To update the payment method on an existing subscription, update the subscription object with {payment_behavior: "default_incomplete"}. Grab the pending_setup_intent.client_secret off of the subscription and return it to the frontend

Client side

• For new subscriptions, call confirmApplePayPayment with the Payment Intent secret to create the subscription and charge the user
• To update the payment method on an existing subscription, call confirmApplePayPayment with the Setup Intent to update the payment method. Apparently confirmApplePayPayment takes in both Payment Intent secrets as well as Setup Intent secrets.
  • For debit card updates, using confirmPayment is the way to go for initial subscriptions/charges, and confirmSetupIntent is the way to go for updating payment information (with their respective secrets as mentioned in the server side part).

I have verified all of the above with webhooks as well as the Event Logs on the developer dashboard. The Apple Pay payment methods and card payment methods all attach to the user each time I create or update a subscription.

[thorsten-stripe]

Thanks @trex-quo for outlining this workaround! It is a good one for subscriptions 👍