Save payment details during payment
Use the Payment Intents API to save payment details from a purchase. There are several use cases:
- Charge a customer for an e-commerce order and store the details for future purchases
- Initiate the first payment of a series of recurring payments
- Charge a deposit and store the details to charge the full amount later
If you’re looking for the individual Card Element guide, see Save a card during payment with the Card Element.
Set up StripeServer-side
First, you need a Stripe account. Register now.
Use our official libraries for access to the Stripe API from your application:
Create a CustomerServer-side
To set a card up for future payments, you must attach it to a Customer. Create a Customer object when your customer creates an account with your business. Customer objects allow for reusing payment methods and tracking across multiple payments.
Enable more payment methods
Card payments are enabled by default. If you want to offer more payment methods, view your payment methods settings in the Dashboard.
Create a PaymentIntentServer-side
Stripe uses a PaymentIntent object to represent your intent to collect payment from a customer, tracking charge attempts and payment state changes throughout the process. Always decide how much to charge on the server side, a trusted environment, as opposed to the client. This prevents malicious customers from being able to choose their own prices.
The payment methods shown to customers during the checkout process are also included on the PaymentIntent. You can let Stripe pull payment methods from your Dashboard settings or you can list them manually. Regardless of the option you choose, know that the currency passed in the PaymentIntent filters the list of payment methods shown to the customer.
Unless your integration requires a code-based option for offering payment methods, Stripe recommends the automated option. This is because Stripe evaluates the currency, payment method restrictions, and other parameters to determine the list of supported payment methods. Payment methods that increase conversion and that are most relevant to the currency and customer’s location are prioritized. Lower priority payment methods are hidden beneath an overflow menu.
Some payment methods can’t be saved during payments. You can still enable these payment methods for other use cases, they just won’t be displayed to customers as an option when setting up future payments. See the Payment method integration options page for more details about what’s supported.
The setup_future_usage
parameter helps optimize future payments made with the same payment method. When both setup_future_usage
and a customer
are provided on a PaymentIntent, the payment details are automatically saved to the customer once the payment is confirmed. You can also supply this parameter when creating the PaymentIntent on your server.
Supplying an appropriate setup_future_usage
value for your application may require your customer to complete additional authentication steps, but reduces the chance of future payments being rejected. See Optimizing cards for future payments to determine which value you should use for your application.
Included in the returned PaymentIntent is a client secret, which the client side uses to securely complete the payment process instead of passing the entire PaymentIntent object. You can use different approaches to pass the client secret to the client side.
Collect payment detailsClient-side
You’re ready to collect payment details on the client with the Payment Element. The Payment Element is a prebuilt UI component that simplifies collecting payment details for a variety of payment methods.
The Payment Element contains an iframe that securely sends the payment information to Stripe over an HTTPS connection. The checkout page address must also start with https://
rather than http://
for your integration to work.
You can test your integration without using HTTPS. Enable it when you’re ready to accept live payments.
The Payment Element renders a dynamic form that allows your customer to pick a payment method. Depending on their payment method, the form automatically requests that the customer fills in all necessary payment details.
You can customize the Payment Element to match the design of your site by passing the appearance object into options
when creating the Elements
provider.
By default, the Payment Element only collects necessary billing address details. In cases where you need to collect full billing address, like for calculating tax for digital goods and services, you can use the Address Element in Billing mode.
Submit the payment to StripeClient-side
Use stripe.confirmPayment to complete the payment using details from the Payment Element. Provide a return_url to this function to indicate where Stripe should redirect the user after they complete the payment. Your user may be first redirected to an intermediate site, like a bank authorization page, before being redirected to the return_url
. Card payments immediately redirect to the return_url
when a payment is successful.
If you don’t want to redirect for card payments after payment completion, you can set redirect to if_required
. This only redirects customers that check out with redirect-based payment methods.
stripe.confirmPayment
may take several seconds to complete. During that time, disable your form from being resubmitted and show a waiting indicator like a spinner. If you receive an error, show it to the customer, re-enable the form, and hide the waiting indicator. If the customer must perform additional steps to complete the payment, such as authentication, Stripe.js walks them through that process.
If the payment succeeded, the card is saved to the Customer object. This is reflected on the PaymentMethod’s customer field. At this point, associate the ID of the Customer object with your own internal representation of a customer, if you have one. Now you can use the stored PaymentMethod object to collect payments from your customer in the future without prompting them for their payment details again.
Make sure the return_url
corresponds to a page on your website that provides the status of the payment. When Stripe redirects the customer to the return_url
, we provide the following URL query parameters:
Parameter | Description |
---|---|
payment_intent | The unique identifier for the PaymentIntent . |
payment_intent_client_secret | The client secret of the PaymentIntent object. |
If you have tooling that tracks the customer’s browser session, you might need to add the stripe.com
domain to the referrer exclude list. Redirects cause some tools to create new sessions, which prevents you from tracking the complete session.
Use one of the query parameters to retrieve the PaymentIntent. Inspect the status of the PaymentIntent to decide what to show your customers. You can also append your own query parameters when providing the return_url
, which persist through the redirect process.
Charge the saved Payment Method laterServer-side
bancontact
and ideal
are one-time payment methods by default. When set up for future usage, they generate a sepa_debit
reusable payment method type so you need to use sepa_debit
to query for saved payment methods.
When you’re ready to charge your customer off-session, use the Customer and PaymentMethod IDs to create a PaymentIntent. To find a payment method to charge, list the payment methods associated with your customer. This example lists cards but you can list any supported type.
When you have the Customer and PaymentMethod IDs, create a PaymentIntent with the amount and currency of the payment. Set a few other parameters to make the off-session payment:
- Set off_session to
true
to indicate that the customer is not in your checkout flow during this payment attempt—this causes the PaymentIntent to throw an error if authentication is required. - Set the value of the PaymentIntent’s confirm property to
true
, which causes confirmation to occur immediately when the PaymentIntent is created. - Set payment_method to the ID of the PaymentMethod and customer to the ID of the Customer.
Test the integration
Use test payment details and the test redirect page to verify your integration. Click the tabs below to view details for each payment method.
Test charging a saved SEPA Debit PaymentMethod
Confirming the PaymentIntent using iDEAL, Bancontact, or Sofort, generates a SEPA Direct Debit PaymentMethod. SEPA Direct Debit is a delayed notification payment method that transitions to an intermediate processing
state before transitioning several days later to a succeeded
or requires_payment_method
state.
See also
Now that you’ve finished your integration, you might want to check out these other resources.