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, SEPA Direct Debit, and TreviPay, 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