Managing payment sessions
Learn the basics of payment sessions and how to migrate your integration.
A payment session tracks a customer's payment throughout the checkout process. Although you're not required to, we highly recommend you use payment sessions to reduce the complexity of building DigitalRiver.js payment collection flows and to comply with PSD2 and SCA regulations.
Migrating to payment sessions is relatively straightforward and mostly involves updating the code for each of your approved payment methods.
Why use payment sessions?
Payment sessions allow you to comply with PSD2 and SCA regulations. When using payment sessions to create credit card sources, Digital River automatically collects the required authentication data from the customer's PSD2 transactions.
Payment sessions also simplify source creation by reducing the data you're required to provide. If you don't use payment sessions, you'll need to copy numerous data points returned in the cart and ensure it is properly formatted before passing them to the create source method.
When creating a source with payment sessions, however, you can provide the unique identifier of the session, thereby minimizing the data you must transfer.
Payment sessions also allow you to gain access to Drop-in Payments, which lessens your front-end development burden. For each transaction, Drop-in Payments retrieve the available payment methods, that are applicable to the transaction and display them as options to customers.
Creating a source with payment sessions
When creating a payment source, specify the sessionId
in the payload that you pass to the DigitalRiver.js create source method. The data needed by our payment services to create the source is then retrieved from that session.
We highly recommend that you use payment sessions when creating a payment source in a cart flow to reduce the complexity of building the DigitalRiver.js payment collection flows and to comply with PSD2 and SCA regulations.
How to determine when to create an order
A cart's payment.session
can be used to determine when to create an order. Specifically, we provide you information on the payment session's state as well as the amount contributed and amount remaining to be contributed.
Session state
The following are the payment session states most important when building your integration:
Requires confirmation
The cart's payment.session.state
must be requires_confirmation
before you convert that cart to an order.
This state
indicates that the cart's payment sources[] are sufficient to fund the transaction. For example, when you attach a chargeable
primary source to a checkout, the amount remaining to contribute drops to zero, and the session's state
transitions to requires_confirmation
.
Requires source
A cart's payment.session.state
can be requires_source
for either of the following reasons:
No primary or secondary payment sources have yet been applied.
No primary payment source is applied and there are not enough secondary payment sources such as store credit to fully fund the transaction.
In both of these scenarios, we won't be able to generate a charge amount large enough to cover the checkout's totalAmount
. So the amount remaining to contribute remains greater than zero and any attempt to create an order is blocked.
Complete
The payment session state
typically transitions to complete
once the order is created.
Amount contributed and amount remaining to be contributed
Once a primary payment source is attached to a cart, we use it to fully fund the transaction.
But when only secondary payment sources are attached, you need to confirm sufficient funds exist to cover the cart's totalAmount
. If this isn't the case, when you convert the cart to an order, you receive the following error:
By comparing values in the cart's payment.session
, you can determine how much additional funding, if any, is still required. The amountContributed
represents the aggregated amount of all the cart's payment.sources[]
. The amountRemainingToBeContributed
is how much is needed to fully fund the transaction.
If the amountContributed
is equal to the cart's totalAmount
or the amountRemainingToBeContributed
is zero, then you don't need to request any more payment methods from the customer. This means that once the payment session is in the correct state, and all address requirements are met, you can convert the cart to an order.
But if the amountContributed
is less than the cart's totalAmount
or the amountRemainingToBeContributed
is greater than zero, then the customer needs to supply additional payment methods before an order can be successfully created. However, this will only be the case when a primary payment source is not yet attached to the checkout. Once that's done, we use it to fully fund the transaction and amountRemainingToBeContributed
drops to zero.
Attaching a source
You can attach a source to a customer, or an order or cart. See Source basics for more information.
Retrieving available payment methods
In DigitalRiver.js, you can use the payment session identifier to return the payment methods available for each transaction and present them to the customer during the checkout process.
The method also returns the data required to use one-click payment methods like Apple Pay and Google Pay, as well as the data needed to retrieve compliance information via the DigitalRiver.js compliance methods.
Migrating to payment sessions
Although we generally recommend that you use Drop-in Payments to handle payments, you can also migrate your existing integration directly to payment sessions. For the Commerce API, payment sessions must be enabled.
Once you have completed this migration process, you'll need to build your SCA workflows using Drop-in Payments or DigitalRiver.js with elements.
Last updated