Source basics
Learn the basics of sources.
Last updated
Was this helpful?
Learn the basics of sources.
Last updated
Was this helpful?
In Commerce APIs, each source type has certain characteristics that determine how it is created and eventually processed. A is associated with a customer's , which the customer uses to fund a transaction. Digital River retrieves data from the 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 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.
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.
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.
The following example shows how to attach a payment method to an order or cart.
The following examples show how to attach a payment method to a customer or payment option.
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 immediately
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 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.
A wide variety of payment methods are available. For a complete list, refer to the page.
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. 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 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 of the source is returned immediately as either chargeable or failed. A credit card is an example of this type of payment method.
You can use some to create reusable sources (recurring payments). This means the customer doesn't need to re-supply the payment details before every transaction. Other can only create single-use sources.
Refer to the 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 . So both and only generate single-use sources. To make them reusable once they're created (assuming the source type supports reusability), you must . 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 reusability, we . So, you should only with a non-reusable source. When you convert the cart to an order, this will generate a one-time charge authorization.
The Commerce API allows you to save payment sources associated with a customer for later reuse. After you , DigitalRiver.js will create a Source and return a sourceId. You can then use that sourceId to .
You can only attach payment methods that . Note that storeCredit does not support recurring payments, so you cannot attach it as a payment option.
You should only attach a Source whose underlying payment method . Otherwise, the reusable value remains false , and the customer can't apply that Source to future orders.
Refer to .
A source's flow attribute represents how your customers experience the payment process and what actions they must take to authenticate a . The enumerated values of the attribute are standard, redirect, and receiver.
redirect: 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 when using redirect payment methods.
Once charged, the status of switches to consumed , and no additional charges can be created from the Source. , however, can maintain a chargeable state.
Sources with a redirect , 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 , 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 to determine whether your integration returns the expected state value.