Checkouts, payment sources, and orders
Learn more about the standards related to processing checkouts, payment sources, and orders.
Last updated
Learn more about the standards related to processing checkouts, payment sources, and orders.
Last updated
This section's and standards cover how to process -compliant checkouts, subscriptions, payment sources, and orders.
Click any checklist item for information on meeting the , , and -related integration standards.
The checkout, payment source, and order standards that apply to your integration depend on which of the above checklists you're using.
Additionally, you should display these response values in your interface so customers can review tax and product totals during the checkout process.
POST/orders response
Due to...
Ready to fulfill?
No
No
No
No
Yes
Upon receipt of either event, retrieve state, fraudState, and charges[].state from the payload and use these values to update the corresponding attributes in the upstream commerce platform's order.
When each must include a identifier or a object. Each line item in the request must also have a defined and a .
When each must include productDetails and within that object, you must specify a skuGroupId.
If you're sending in , your integration should pass your system's unique product identifier as the object's id.
For more information, refer to the section on the .
If you're sending in , your integration must reference the product's associated . You do this by specifying a skuGroupId in the productDetails object.
For more information, refer to the section on the .
When , use the taxInclusive flag to indicate whether the in an order should be treated as .
When , provide the IP address of the customer's browser used to place the order.
For tracking purposes, specify an during the that matches the identifier of the corresponding order in your commerce platform.
Orders that contain must provide and address information.
Each time you create or update a checkout, to update price, fee, and tax information in the upstream commerce platform. These updates should be performed for the entire transaction and each line item. This ensures that the values in your system stay in sync with those in our system.
Since the customer actively participates in a subscription acquisition, you should set to .
During a subscription's autorenewal, the customer is not an active participant. As a result, when to process an autorenewal, you should set to .
Any transaction that includes a recurring product or service must provide information that describes that subscription. So, when , provide these details in the hash table.
For , you must display the subscription's terms and acquire the customer's active acceptance of them. So, before , pass these agreed-upon terms in the checkout's parameter. This ensures that they are recorded in the .
During the acquisition process, you can optionally generate a unique subscription identifier and assign it to .
For every recurring product or service, you must use the parameter to tell us whether the subscription is automatically or manually renewed.
During the renewal process, send the generated during the subscription's acquisition.
When acquiring or renewing a subscription with the payment method, you must .
are our all-in-one solution for handling payments and ensuring compliance. We recommend you use this solution as a quick and easy way to start accepting payments.
During the checkout experience, you can use the to present available payment methods and safely and securely capture a customer's payment details. The returned in the can then be before the customer arrives on your order review page.
During checkout flows, we recommend you allow customers to save their payment information for future transactions. When for and purchases, you can to customers.
In the event, if returns true or mandate is populated, then the customer agrees to save that transaction's payment information for future use. Your integration should .
Whenever successfully create a , we send you the . Once you receive this event, redirect the customer to the order review page. The customer can review the order's details before deciding whether to purchase.
When a customer purchases an auto-renewing subscription, the payment methods that display must . To ensure that Drop-in only displays , set to true in a POST/checkouts or POST/checkouts/{id} request. You then use Drop-in's configurable to set showTermsOfSaleDisclosure to true.
When acquiring an auto-renewing subscription, customers must agree to save the transaction's payment source to their account so that it can be applied to renewals. So, you must configure to display the combined subscription save payment agreement terms and then acquire the customer's active acceptance.
You do this by first setting to true in a POST/checkouts or POST/checkouts/{id} request. You then use Drop-in's configurable to set showTermsOfSaleDisclosure to true.
When the event returns a source that is , you should save the source to the customer's account. This operation flips its reusable value to true. As a result, the source can be used in subscription auto-renewals.
After you display the review order page to the customer and the customer actively accepts Digital River's and then submits the order on the storefront, you should .
Digital River creates an based on the data in a . Providing checkoutId in the payload of POST/orders acts primarily as a call to authorize payment and trigger a fraud review.
When a customer uses a such as a to pay for a transaction, the almost always immediately returns an or order. When the order succeeds, direct the customer to the "Thank you" page. If the order fails, use the error's message to inform the customer of the issue through the user interface.
When the returns a status code, retrieve the order's id from the payload and use that value to set the corresponding attribute in the upstream commerce platform's order.
Use the to set the status of the upstream commerce platform's order.
a
a
a
an
an
When the returns a status code, retrieve charges[].state from the payload and use that value to set the corresponding attribute in the upstream commerce platform's order.
For set the commerce platform's order payment status to failed.
When the returns a status code, retrieve fraudState from the payload and use that value to set the corresponding attribute in the upstream commerce platform's order.
For set the commerce platform's order fraud status to blocked.
We send the event when Digital River successfully authorizes payment and completes its fraud review. This event indicates that the order is ready to be fulfilled. Upon receipt, retrieve state, fraudState, and charges[].state from the payload and use these values to update the corresponding attributes in the upstream commerce platform's order.
An asynchronous payment authorization failure triggers an event. When Digital River asynchronously detects an anomaly during its fraud review or the customer is determined to be on the , we send an event.
For each subscription product or service you create, store the that Digital River generates so that it can be sent in the renewal request.
: order.accepted, order.review_opened, order.pending_review, order.pending_payment, order.blocked, order.charge.failed, order.complete