Last updated February 1, 2021

Payment methods overview

This article provides an overview of different payment methods in Flex.

Introduction to payments in Flex

Enabling customers to pay for their bookings and handle the transaction flow efficiently is one of the most valuable features of Flex. Flex leverages Stripe for payments and offers multiple different ways for customers to pay for transactions. The following are the currently supported payment methods, divided into two categories - pull and push payment methods:

Pull payment methods
- card payments
- similar to card payments (Google Pay, Apple Pay, Microsoft Pay)
Push payment methods
- Alipay
- Bancontact
- EPS
- giropay
- iDEAL
- Przelewy24

In Stripe's terms, Flex supports payment methods that have immediate payment confirmation (see the table in this section of Stripe's guide to payments) and that are supported by Stripe's PaymentIntents API. Mostly, these payment methods fall under either Cards, Bank redirects, or Wallets in Stripe's classification.

Note: Flex does not support payment methods that require the use of Stripe's older Sources API.

This article presents how payments flow depending on whether you use card (or similar) payments or have enabled any other push payment method. The article also describes the tradeoffs you need to consider in designing the transaction process involving payments.

Money flow in different scenarios

Understanding how money flows when using card payments or push payments is crucial for understanding how to design the transaction process in Flex.

Card payment flow

For card payments, the payment flow starts with a preauthorization. The money is reserved but not yet charged from the customer's credit card. After a charge, Stripe moves money to the provider's Connect Account Balance in Stripe and holds it there until a payout is issued.

The preauthorization is valid for seven days, after which Stripe automatically releases it. You can use the preauthorization to configure the transaction process to allow the provider to accept or decline the transaction. If the provider declines the transaction, Stripe collects no processing fees since money has not been transferred.

Finally, the transaction process can hold money in Stripe until an explicit payout (The hold should not exceed three months). The mechanism allows you to build a transaction process where the money is in an escrow-like hold until an explicit payout. The hold ensures some safety for the customer as the marketplace controls the money until a payout. The process can issue the payout in a separate transition.

Push payment flow

For push payments, there is no preauthorization. Once the customer confirms the payment, it gets captured automatically and a charge is made immediately. The charge moves money immediately to the provider's Stripe Connect account.

This means that refunds can be issued only at a point where money has already moved and the marketplace must cover Stripe fees. You should take this into account when designing the transaction process of your marketplace. Either declining the transaction should be disabled, handled through availability management, or accounted for in commissions.

The rest of the money flow is the same as with card payments and has the same features and capabilities.

Using different payment methods in your marketplace

Customizing the transaction process

The default transaction process in Flex supports card payments. The general article on the transaction process describes the process in more detail.

A note on Google Pay, Apple Pay, and Microsoft Pay

Even though Google Pay, Apple Pay, and Microsoft Pay are similar to card payments, they require some changes to the default implementation of FTW. To enable them in FTW, you need to follow the Stripe instructions on the Request Payment Button.

If you wish to enable push payments, you need to adapt your transaction process. For instance, you need to add a new transition that includes the stripe-create-payment-intent-push action. Further, because push payments do not have a preauthorization phase, it is recommended to avoid that in the transaction process and use an instant booking type of flow. The example below describes the minimum recommended changes in the two transitions: request-push-payment and confirm-payment-instant-booking. The example illustrates how you can still use the preauthorization step for card payments.

You can find another example process with only an instant booking flow and support for both card and push payments in the Instant booking process in the Flex example transaction processes repository.

Handling payment methods in the client app

See this section in the PaymentIntents guide.