Flows by payment type
Understand the flows by payment type.
Last updated
Was this helpful?
Understand the flows by payment type.
Last updated
Was this helpful?
Each payment method must follow a specific payment flow to ensure a seamless payment process. The payment flows and corresponding payment methods outlined below follow Digital River's recommended best practices.
Use the following flow for standard payments: , , and .
.
.
. The source state
is chargeable
.
.
.
Use the following flow for delayed payments, such as .
Get the store details.
. The source state
is pending_funds
.
The customer transfers the funds to the Konbini payment provider.
The source state
changes to chargeable
when the funds are received.
.
Optional. Set the locale and currency.
curl --location --request GET 'https://{host}/v1/shoppers/me.json? locale=pt_BR¤cy=BRL' --header 'Content-Type: application/json'--header 'authorization: bearer ***\
Optional. Set the cart address to the BR
address.
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:
If you get a 201 Created
response, then redirect the customer to the redirectUrl
, where they can either approve or cancel payment. Once the customer completes either of these actions, they're redirected to the URL you assigned to cancelUrl
or returnUrl
.
If you receive a 409 response with the error "Requisition is not present or not in Source Pending Redirect state", this indicates something went wrong. You must recreate the cart and return customers to the payment collection stage.
To use as a payment method:
.
. The action inserts the tax ID into the payment session.
with a payment session ID. Note that the tax ID is required when creating the Boleto source. The payment session ID provides the tax ID.
.
.
Use the following flow for delayed payments, such as .
.
.
. The source state
is chargeable
.
.
.
The shopper receives the payment details and completes the payment. After the shopper finalizes the payment, the updated order status will appear in .
Use the following flow for RTS payment methods, such as , , , , , and
.
.
. The source state
is pending_redirect
.
.
. The session state
is requires_confirmation
.
.
If you're using and customers opt to fund a transaction with a , such as , , and , whose resulting has a of redirect
must be redirected to the payment provider, where they either approve or cancel the funds transfer.
You should before making payment to ensure customers avoid situations where they might send payment, but the Digital River order remains incomplete.
The table in the section provides a full list of payment methods that require an .
In the method's , set the object's disableAutomaticRedirects
to true
. Assign the returnURL
to be your completion step, such as the order confirmation page. cancelURL
should return the customer to the cart or store workflow
If customers select a redirect payment method, the data
returned by contains a whose is pending_redirect
. When you receive this event, retrieve the source.id
from the data
.
Next, pass this identifier in a server-side .
At this point, retrieve the data you need—such as currency
, orderTotal
, subTotal
, tax
, billingAddress
, shippingAddress
,payment.sources[]
, and relevant lineItems
—to build a review page.
If customers click your submit order button after reviewing the transaction's details, send a .
When the returnUrl
loads, call a function that initiates a server-side request, and send the resume call. You do not need to perform this call if the customer goes to your cancelUrl
.
If you get a 200 OK
repsonse, verify the is Submitted
and paymentSession
status is complete
. You can render the order confirmation page to the customer.
Use the STR payment flow for , , , , , , , , , , , , , , , , , , and .
.
.
. The source state is pending_redirect
.
. The session state
is requires_confirmation
.
. The session state
is pending_redirect
.
to complete post-order processing.
The Submit then Redirect (STR) sequence diagram illustrates the interactions between the client, server, and external payment provider during the . It includes key steps such as applying the shopper to a cart, handling session states, and completing the redirect authorization, ultimately leading to successful payment processing. The scope of the following diagram is limited to the operations in this flow.