Comment on page
Source basics
Learn the basics of sources.
In Commerce APIs, each source type has certain characteristics that determine how it is created and eventually processed. A source is associated with a customer's payment method that a customer uses to fund a transaction. Digital River retrieves data from the source when generating a charge.
A source's
type represents the payment method used to create that object. You can find a full list of these type values on the Sources API reference page. A source also contains a hash table with a name corresponding to its
type. This data object holds detailed information specific to that type. For example, a source with a type of credit card has a creditCard hash table that lists the card's brand, expirationMonth, expirationYear, and lastFourDigits.Source
{
...
"type": "creditCard",
...
"creditCard": {
"brand": "MasterCard",
"expirationMonth": 5,
"expirationYear": 2025,
"lastFourDigits": "0008"
},
...
}
There is a wide variety of payment methods available. For a complete list, refer to the Supported payment methods page.
The following sections explain the methods for charging a payment method and how a customer experiences the payment process.
The difference between a pull and push payment method involves how a customer's funds are transferred.
Customers provide their information and consent for a pull payment method, and the money is drawn from their accounts. No additional customer actions are typically necessary. Credit cards are the most common example of this payment method type.
When using a push payment method, the customer must explicitly send the funds before a charge can become capturable. These payment methods almost always require additional customer action. For example, if you enable wire transfers on your website or app, you'll present your customers with the necessary transfer information to complete the payment, and they must "push" the funds.
With synchronous payment methods, the
state of the source is returned immediately as either chargeable or failed. A credit card is an example of this type of payment method. With asynchronous payment methods, the source may first return with a
state of pending_funds, source_pending_redirect, or requires_action before it can transition to chargeable. PayPal is an example of an asynchronous payment method because the customer is redirected to the PayPal site and must take additional action to authorize the transaction. You can use some payment methods to create reusable sources (recurring payments). This means the customer doesn't need to re-supply the payment details before every transaction. Other payment methods can only create single-use sources.
Refer to the Supported payment methods page for a list of payment methods that support recurring payments. Additionally, specific reusable payment methods can be restricted to single-use as part of the enablement process.
Sources must have a
reusable value of true before they can be used to make multiple charges. Reusable sources can't be created using a public API key. So both Drop-in payments and DigitalRiver.js with elements only generate single-use sources. To make them reusable once they're created (assuming the source type supports reusability), you must save the source to a customer. This flips reusable to true and prevents the source's state from becoming consumed once it's associated with a transaction.If a source's underlying payment method doesn't support re-usability, we block the source from being saved to a customer. So, with a non-reusable source, you should only attach the source to a cart. When you convert the cart to an order, this will generate a one-time charge authorization.
The following example shows how to attach a payment method to an order or cart.
POST /v1/shoppers/me/carts/active/apply-payment-method
{
"paymentMethod": {
"sourceId": "e7ba0595-059c-460c-bad8-2812123b9313"
}
}
The Commerce API allows you to save payment sources associated with a customer for later reuse. After you submit a customer's payment details, DigitalRiver.js will create a Source and return a
sourceId. You can then use that sourceId to attach the Source to a payment option.The following examples show how to attach a payment method to a customer or payment option.
You can only attach payment methods that support recurring payments. Note that
storeCredit does not support recurring payments, so you cannot attach it as a payment option.Attaching source to a customer
Attaching a source to a payment option
curl --location --request POST 'https://<<host>>/v1/shoppers/me/payment-options' \
--header 'Content-Type: application/json' \
--header 'authorization: bearer ***\
--data-raw '
{
"paymentOption": {
"nickName": "My Visa Card",
"isDefault": "true",
"sourceId": "61033d62-c0f4-4a7e-b844-07daf26ba84e"
}
}
curl --location --request POST 'https://<<host>>/v1/shoppers/me/payment-options' \
--header 'Content-Type: application/json' \
--header 'authorization: bearer ***\
--data-raw '
{
"paymentOption": {
"nickName": "My Token",
"isDefault": "true",
"sourceId": "61033d62-c0f4-4a7e-b844-07daf26ba84e"
}
}'
You should only attach a Source whose underlying payment method supports reusability. Otherwise, the
reusable value remains false , and the customer can't apply that Source to future orders.A source's
flow attribute represents how your customers experience the payment process and what actions they must take to authenticate a payment method. The enumerated values of the attribute are standard, redirect, and receiver.standard: In this flow, which mainly applies to credit cards, you obtain a customer's payment details on your storefront and submit this information to Digital River. The customer is never required to leave your website during the checkout process. The customer requires no additional action after they submit their information, and a charge can be created immediatelyredirect: This authentication flow type lets you obtain a customer's payment data on your storefront. You then redirect them to the payment method's website, asking them to authorize the transaction. Once the authorization is confirmed, a charge can be created. We recommend you adhere to these guidelines when using redirect payment methods.receiver: This flow type requires that a customer push funds to an account before a charge can be created. Bank and wire transfers are two common payment methods that use this authentication flow.
A payment source also has a
state attribute which provides information about what can be done with it. The following values enumerate the Source's state: cancelled, chargeable, consumed, failed, and pending. Once charged, the status of single-use sources switches to
consumed , and no additional charges can be created from the Source. Reusable sources, however, can maintain a chargeable state. Sources with a redirect authentication payment flow, such as PayPal, often are in a state of
pending_redirect because the customer must leave your website to confirm the payment.For sources with a receiver authentication payment flow, such as wire transfers, it may take days before the funds are confirmed by the receiving bank or financial institution, thereby switching the source from
pending_funds to chargeable.For different success and error scenarios, you can create tests to determine whether your integration returns the expected
state value.Once all the captures are complete, the customer's payment method is charged the
amount value contained within the source, considering any cancellations you create or refunds you issue.Last modified 3mo ago