Handling redirect payment methods
Gain a better understanding of how to handle transactions funded with a redirect payment method
Last updated
Gain a better understanding of how to handle transactions funded with a redirect payment method
Last updated
If you're using Drop-in payments with Direct Integrations and customers opt to fund a transaction with a payment method whose resulting has a flow of redirect. For example, Bancontact, Klarna, and SEPA Direct Debit must be redirected to the payment provider, where they either approve or cancel the funds transfer.
To do this, we recommend you submit the and then redirect the customer.
Refer to the Supported payment methods table to access a full list of payment methods that require a submit then redirect flow.
On this page, you find:
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 checkout request.
This operation moves the checkout's payment.session.state to requires_confirmation.
If its value is pending_redirect, and payment.session.nextAction.data.redirectUrl is a non-null value, then redirect to this URL. This URL goes to the third-party provider's interface, where customers either approve or cancel payment.
If the order's state is pending_payment and the payment.session.state is pending_funds, refer to Handling delayed payment methods.
Once customers complete either of these actions, they're redirected to the endpoint you assigned to cancelUrl and returnUrl.
At this point, you can initiate fulfillment operations.
The following diagram's scope is limited to the operations described above in How to implement a submit then redirect flow.
Refer to the Core Commerce flow (with submit then redirect) to view a diagram comprehensively covering the checkout, payment authorization, and fulfillment process.
At this point, retrieve the data you need—such as currency, totalAmount, subTotal, totalTax, shipTo, shippingChoice,payment.sources[], and relevant items[].productDetails—to build a review page.
If customers click your submit order button after reviewing the transaction's details, handle that event by passing the id to your server and sending it in the body of a create order request.
If you recieve a 201 Created, and the is pending_payment, then check payment.session.state.
When this resource loads, call a function that initiates a server-side request and sends the identifier and refresh in the path.
If you get a 200 OK, check the order's and payment.session.state.
If (1) is accepted or in_review or (2) state is pending_payment and payment.session.state is pending or pending_funds, then a on the sources[] whose flow is redirect has been successfully authorized, and you should display an order confirmation page and send a confirmation email.
Any other (1) value or (2) combination of state and payment.session.state values indicate that the can't be recovered. As a result, you'll need to recreate the and send customers back to the payment collection stage. For details, refer to Handling rejected orders.
