Source basics

Learn the basics of sources.

A source is associated with the customer's payment method that a customer uses to fund a transaction. When generating a charge, Digital River retrieves data from the source.

In the Digital River APIs, each source type has certain characteristics that determine how it's created and how a charge is eventually processed.

Source types

A source's type represents the payment method used to create that object.

On the Sources API reference page, you can find a complete list of type values.

A source also contains a hash table that corresponds to its type. This data object holds detailed information specific to each 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.

{
    ...
    "type": "creditCard",
    ...
    "creditCard": {
        "brand": "MasterCard",
        "expirationMonth": 5,
        "expirationYear": 2025,
        "lastFourDigits": "0008"
    },
    ...
}

Characteristics of payment sources

A source's characteristics revolve around the pull or push, synchronous or asynchronous, reusable or single-use, primary or secondary, and payment flow.

Pull or push

The difference between a pull and push payment source involves how a customer's funds are transferred.

With pull sources, customers provide their information and consent, and the money is drawn from their accounts. No additional customer actions are usually necessary. Credit cards are the most common example.

When using a push payment source, the customer must explicitly send the funds before a charge can become capturable. These payment sources almost always require additional customer action. For example, if you enable wire transfers on your website or app, you'll need to present your customers with the necessary transfer information to complete payment, and they must then "push" the funds.

Synchronous or asynchronous

With synchronous payment methods, the state of the resulting source is returned immediately as either chargeable or failed. A credit card is an example of this source type.

With asynchronous payment methods, the source may first return in state of pending_funds, pending_redirect, or requires_action before it transitions to chargeable. For example, a source with a type of payPal is asynchronous because the customer is redirected to the PayPal site and must take additional action to authorize the transaction.

When integrating asynchronous payment methods, you can create a webhook to listen for the event with a type of source.chargeable. This will allow you to determine when to attach the source to a checkout or save the source to a customer's account.

Reusable or single-use

Some payment methods can be used to create reusable sources, meaning they support recurring charge authorizations. In customer-initiated transactions, you can present stored sources to customers for convenience. You can also use reusable sources in merchant-initiated subscription renewals.

Other payment methods only create single-use sources.

Refer to the Supported payment methods page for a list of payment methods that support recurring payments. Additionally, as part of the enablement process, certain payment methods that are typically reusable can be restricted to single-use only.

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. As a result, both Drop-in payments and DigitalRiver.js with elements only generate single-use sources. To make them reusable once created (assuming the source's 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 the checkout.

If a source's underlying payment method doesn't support reusability, we block the source from being saved to a customer. As a result, with non-reusable sources, you should only attach the source to a checkout. When you convert the checkout to an order, this will generate a one-time charge authorization.

Primary or secondary

Refer to primary and secondary sources

Authentication flow

A source's flow represents how your customers experience the payment process and what authentications they must complete. The enumerated flow values 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. Customers require no additional action after they submit their information, and a charge can be created immediately

  • redirect: In this flow, you obtain a customer's payment data on your storefront. You then redirect them to the payment provider, 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 requires that customers push funds to an account before a charge can be created. Wire transfer is a common payment method that uses this authentication flow.

Source state

A source's state provides information about what can be done with the object. The source's state may be cancelled, chargeable, consumed, failed, requires_action, pending_funds, or pending_redirect.

Digital River only creates a charge object when the source is chargeable. You can listen for source.chargeable events to be notified of when the source transitions to this state.

Once charged, the state 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 flow of 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 flow of 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's state from pending_funds to chargeable.

For different success and error scenarios, you can create tests to determine whether your integration returns the expected state.

Source amount

Once all 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.

Each time that Digital River returns an updated source, the value of amount can change. For example, if customers add or subtract items from their carts late in the checkout process, and you then update the checkout, the source is returned with an updated amount.

Last updated