Processing other payment methods

The remaining payment method types are redirects—where a customer leaves your application to pay somewhere else—and installment plans—where a customer pays incrementally with a small loan. Our guide to payment methods explains the differences between payment methods, including which geographic regions they’re popular in. Adding support for a new payment method is a two-step process:

1. Enable the payment method in the Dashboard.
2. Use the individual payment method guides to implement it.

We plan to support all payment methods on the Payment Methods API. In the meantime, you can use the Sources API to collect any payment method not yet supported.

The Payment Methods API

The new Payment Methods API replaces the existing Tokens and Sources APIs as the recommended way for integrations to collect and store payment information. It works with the Payment Intents API to create payments for a wide range of payment methods.

A PaymentMethod object is stateless, relying on the PaymentIntent object to represent the transaction state of a given payment.

If your integration currently uses the Sources or Tokens API, follow the migration guide to transition to the Payment Intents and Payment Methods APIs.

The Sources API

Need to use a payment method that’s not yet supported by the Payment Methods API? Use the Sources API instead. The main difference between the Payment Methods API and the Sources API is that sources describe transaction state through the status property, which means that each Source object must be transitioned to a chargeable state before it can be used for a payment.

Testing

When creating a test Source object that uses a redirect flow (e.g., iDEAL), you can follow the URL returned in the redirect[url] field. This leads to a Stripe page that displays information about the API request, and where you can either authorize or cancel the payment.

Authorizing the payment redirects you to the URL specified in redirect[return_url].