Stripe supports a diverse range of payment methods that you can choose from to collect funds from your customers. Each method has a set of unique attributes tailored to different business types and customer locations. When choosing the payment methods you want to enable for your application, it is important to understand how their characteristics will affect customers as well as how the business implements them.
This post explores how different payment methods behave with regards to payment confirmation. Stripe categorizes payment confirmation as either immediate or delayed, representing the speed at which payment methods return a status after an attempted payment. Credit cards, for example, return a payment status immediately while other payment methods like bank debits require some more time to process.
In the Stripe Dashboard, you can quickly toggle on or off the payment methods as needed. However, if your application isn't equipped to handle the varying behaviors of different payment methods, it could lead to issues for your business.
Immediate Confirmation
Credit cards are one of the more commonly used payment methods that offer immediate notification when a transaction is attempted. They are usually enabled by default in a Stripe account. You can verify this by navigating to the Payment Methods section of the Payment settings in the Dashboard. Stripe payment options like Checkout, Payment Links and the Payment Element inspect the configured payment methods to know what options to display to the user. These options use a dynamic payment methods strategy which takes into account factors such as the customer’s location, device type, and local currency.
To learn how credit card payments behave in Stripe, you can use Workbench along with the Stripe CLI in the browser to observe all the generated activity. If you are unfamiliar with Workbench, it is an in-browser tool for debugging and monitoring Stripe payment integrations. It is integrated into the Dashboard experience so there is no need to install or pay anything to use it.
If Workbench isn’t available in your Stripe account, navigate to the following link to enable it: https://dashboard.stripe.com/workbench.
Assuming that the Stripe account you are logged into has prices and products already setup, create a Checkout session using one of the products using the Stripe CLI. Also, make sure the account is in test mode so that any changes made do not affect the production environment. To do this, open Workbench by selecting it from the Developers menu in the upper right side of the Dashboard screen.
Within Workbench, select the Shell tab. This activates a terminal session in your browser where you can issue commands against your Stripe account using the Stripe CLI.
To create a Checkout session, enter the following command into the terminal, remembering to replace the price ID in the line items property with one of your own.
stripe checkout sessions create --success-url="https://example.com/success" --mode=payment -d "line_items[0][price]"=your-own-price-id -d "line_items[0][quantity]"=1
Click on the link provided in the url property of the response to open up the checkout sessions in your browser. Choose Card as the payment method, fill out the payment information using one of Stripe’s test cards, and submit the form.
Back in the Workbench, click on the Events tab and you will see a number of events have been triggered from that Checkout session. The three important ones to pay attention to are charge.succeeded, payment_intent.succeeded, and checkout.session.completed. These are the events your application must watch for to know whether a card payment was successful or not. Clicking on any one of these events allows you to review the respective event details.
The checkout.session.completed event has a payment_status property that can be set to either paid, unpaid, or no_payment_required. This is the property your payment integration code must inspect to confirm the checkout payment. This is often confused with the status property on the checkout.session.completed event, which can be set to open, complete, or expired. A completed checkout session does not mean that there was a successful payment. Instead, it is an indication that the customer successfully submitted the form on the checkout page.
The charge.succeeded and payment_intent.succeeded events also signal that there was a successful payment but they do not contain any information that relates back to the initial checkout session.
Delayed Confirmation
Other payment methods like bank debits, bank transfers, and cash-based vouchers can take a few days to process before they return a payment confirmation. Because of this, your integration has to look out for additional events from Stripe when working with these types of payments.
In the Payment Methods section of the Dashboard, the various payment method options are shown for your account along with a brief summary of what they support.
The image above shows the supported bank debit options for an account. Notice that for ACH Direct Debit payment confirmation supports refunds, recurring payments, and can take up to five days to process. To see how delayed payment confirmations work with a checkout session, enable one of these payment methods and execute the same command from above in the in-browser shell.
stripe checkout sessions create --success-url="https://example.com/success" --mode=payment -d "line_items[0][price]"=your-own-price-id -d "line_items[0][quantity]"=1
After opening the generated checkout link in your browser, you should see the option to use the bank debit method that was just enabled. If the option doesn’t show, check that the payment method was successfully enabled and that it supports the currency of the price you provided.
To try out ACH Direct Debit without providing real banking information, complete the payment form using the Test Institution option on the form. After submitting the payment, return to the Dashboard, open the Events tab in Workbench.
A different batch of events are triggered for this new checkout session. Inspecting the payload of the checkout.session.completed event reveals that payment status is unpaid even though the checkout session was successfully completed.
The associated payment intent and charge objects enter an intermediary state before successfully completing. A new event named checkout.session.async_payment_succeeded is also triggered. In test mode, this event shows up almost immediately but it can take a few days to be seen in production.
When working with payment methods that have delayed notifications, this is one of the events your application must listen for to find out the status of the payment. A checkout.session.async_payment_failed event is sent instead if the payment failed. Inspecting the payload of checkout.session.async_payment_succeeded event in Workbench reveals that the payment status for this checkout session is now paid.
Conclusion
It is important to understand how different payment methods behave when building out a payments integration. Knowing what events and properties to look for can save you time and prevent the business from losing money. The tools available in Workbench provide deeper insights into how different payment methods behave in Stripe and how your application can properly integrate with them. Take a look at the Workbench documentation to delve deeper into its other capabilities.