Managing sources
Learn how to manage payment sources
Last updated
Learn how to manage payment sources
Last updated
In the Digital River API, fall into two broad categories: .
For both categories, after , you can always so that Digital River can attempt to generate a after you . You can also .
If a supports , you may also be able to . For with multiple sources[]
, we also provide you the ability to .
You can , but how you sequence their application depends on whether or not the primary source is .
When , the exposes methods for and sources useful in the purchase and account management scenarios.
When , you should know the differences between and payment sources and how they affect the .
Primary payment are created from traditional such as , , , and . Most customers use a primary source when making a purchase, but a sources[]
can only contain one primary source.
Primary sources created from may be able to be and then in future transactions.
Alternatively, you can simply , thereby enabling Digital River to submit a after you .
Once a contains a primary source, the are met to .
Secondary payment are typically used to supplement a .
In the Digital River APIs, secondary sources have a of .
For versions:
At this point, you can update your system and notify customers that the payment method has been saved to their account.
If you attempt to reattach this source to a customer, you'll receive the following error:
Customers can store multiple payment sources[]
.
If a only contains secondary sources[]
, you may be able to successfully , but before doing so, you must ensure the .
Secondary sources do not support . Therefore, they . They can only be to create a one-time upon creation.
We provide multiple options for and .
are created with your using or . Once created, you can or, in some cases, .
How you create with a of customerCredit
depends on the you're using.
2021-03-23
and higher, refer to .
2020-09-30
, 2020-12-17
, and 2021-02-23
, refer to .
A sources[]
can hold a single and/or one or more .
In , you can combine a secondary source with any primary source that has one of the following values: alipayCn
, creditCard
, googlePay
, applePay
, payPal
, payPalCredit
, payPalBilling
, wireTransfer
, klarnaCredit
, klarnaCreditRecurring
, alipay
, konbini
, directDebit
and onlineBanking
.
You can also use secondary sources with any primary payment sources in . Just make sure you turn off . For details, refer to .
When , ensure you're properly sequencing the application of primary and secondary sources. The sequence depends on whether you use or .
Also, you should be aware of when an contains multiple .
If a primary source is created during the checkout process and then not (perhaps because the customer is checking out as a , the customer is but chooses not to save the , or the source's doesn’t support ), you must attach all to the before attaching the primary source.
If a primary sources[]
has a value that is false
, then any attempt to returns the following error:
If a checkout's primary is saved to the , then you have more flexibility in how you sequence the application of and sources.
More specifically, if a checkout's primary sources[]
has a value of true
, then you can request to . Each time this request is successfully submitted, the checkout's primary sources[].amount
gets reduced by the secondary amount
.
When , you should be aware of how Digital River processes , , and on an charges[]
.
Digital River first the created from and then the single charge from the .
Digital River first the single created from the and then the charge(s) created from .
Digital River first the single created from the and then the charge(s) created from .
After you or a payment and retrieve its unique identifier, you can use that value to associate the source with a .
You do this by or . This is true for both .
You're only allowed to associate one with a checkout. If a checkout's sources[]
contains a primary source, and you submit a request to attach a different primary source, using either the or approach, then the existing source is replaced.
However, as long as the aggregated amount
of all of a checkout's sources[]
doesn't exceed the checkout's totalAmount
, there's no limit to the number of you can attach to a checkout.
To associate a payment with a , you can send its sourceId
in the body of a or request.
To associate a payment source with a , you can pass the checkout's identifier and the source's identifier as path parameters in a .
When you need to remove a payment source from a checkout, you can send a . A successful request returns a 204 No Content
status code and an empty body.
If the source's value is false
when you submit the detach request, then the source's transitions to cancelled
, and any attempt to returns the following error:
In some cases, after you , you can save it to a customer for use in future checkouts.
Attaching to can be useful when that allow customers to save their payment information during , , or on .
As long as the are satisfied, you can save a to a by sending their unique identifiers as path parameters in a request.
A successful request flips the source's value to true
and returns the source.
Before sending a , make sure that the doesn't have any and restrictions.
If a doesn't support and you pass its identifier in a , then the following error is returned:
For a list of payment methods that can be used in recurring transactions, refer to the page.
With , you can also use supportsStorage
in the event's data
to make this determination.
Only whose is chargeable
can successfully be saved to a . If the isn't chargeable
(perhaps because it has a redirect
payment , the customer has yet to successfully authorize payment, and, as a result, its is still pending_redirect
), and you attempt to , you'll receive the following error:
With , you can use readyForStorage
in the event's data
to determine whether a can be associated with a .
A saved to a can't be used to unless you associate the with the .
If a has a saved sources[]
, and you but neglect to , you'll receive the following error when you .
If you'd like to detach a payment saved to a customer, you can send a request. When you do so, the source's becomes cancelled
and the resource can't be used to .
The first automatically becomes its default, and its identifier is assigned to the customer's defaultSourceId
attribute. If you'd like to assign a customer a different default payment source, you must first ensure it's . Once that's done, you can set its identifier as the defaultSourceId
in an .
After you , you can pass its identifier, identifier, and client secret to the in the library. This operation is especially helpful when that allow customers to retrieve saved credit card information during or .
After you , you can pass its identifier, identifier, and client secret to the in the library. This operation is useful when that allow customers to .