Handling redirect payment methods
Gain a better understanding of how to handle transactions funded with a redirect payment method
If you're using Drop-in payments and customers opt to fund a transaction with a payment method, such as Bancontact, Klarna, and SEPA Direct Debit, whose resulting source has a flow of redirect must be redirected to the payment provider, where they either approve or cancel the funds transfer.
We recommend submitting the cart and then redirecting the customer to do this.
Refer to the table in the Supported payment methods section for a list of payment methods that require a submit then redirect flow.
On this page, you find:
How to implement a submit then redirect flow
In the createDropin() method's configuration object, set the redirect object's disableAutomaticRedirects to true and assign the same value to both returnUrl and cancelUrl.
If customers select a redirect payment method, the data returned by onSuccess contains a source whose state is pending_redirect. When you receive this event, retrieve source.id from data.
Next, pass this identifier in a server-side attach source to an order or cart.
This operation moves the source into "pending redirect" state, the order state to "Source pending redirect", and provides you with the redirectUrl to present to the customer:
At this point, retrieve the cart data you need—such as currency, orderTotal, subTotal, tax, billingAddress, shippingAddress,payment.sources[], and relevant lineItems —to build a review page.
If, after reviewing the transaction's details, customers click your submit order button, handle that event by passing the checkout's id to your server and sending it in the body of a create order request.
If you get back a 201 Created, and the order's state is pending_payment, then check payment.session.state.
If its value is pending_redirect, and payment.session.nextAction.data.redirectUrl is a non-null value, then redirect customers to this third-party provider's interface URL, where they can either approve or cancel payment.
If the order's state is pending_payment and the payment.session.state is pending_funds, refer to the Delayed payment flow section.
Once customers complete either of these actions, they're redirected to the endpoint you assigned to cancelUrl and/or returnUrl.
When this resource loads, call a function that initiates a server-side request and sends the order's identifier and refresh in the path.
If you get a 200 OK, check the order's state and payment.session.state.
If (1) state is accepted or in_review or (2) state is pending_payment and payment.session.state is pending or pending_funds, then a charges[] on the sources[] whose flow is redirect has been successfully authorized, and you should display an order confirmation page and send a confirmation email.
At this point, you can initiate fulfillment operations.
Any other (1) state value or (2) combination of state and payment.session.state values indicate that the order can't be recovered. As a result, you'll need to recreate the checkout and send customers back to the payment collection stage. For details, refer to Handling rejected orders.
Last updated
Was this helpful?