# Source basics In Commerce APIs, each source type has certain characteristics that determine how it is created and eventually processed. A [source](https://docs.digitalriver.com/commerce-api-references/admin-apis/payment-source/source-management) is associated with a customer's [payment method](/commerce-api/payments/supported-payment-methods.md), which the customer uses to fund a transaction. Digital River retrieves data from the [source](https://docs.digitalriver.com/commerce-api-references/admin-apis/payment-source/source-management) when generating a charge. ## Source types 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 [Source management](https://docs.digitalriver.com/commerce-api-references/admin-apis/payment-source/source-management) 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`. {% tabs %} {% tab title="Source" %} ```json { ... "type": "creditCard", ... "creditCard": { "brand": "MasterCard", "expirationMonth": 5, "expirationYear": 2025, "lastFourDigits": "0008" }, ... } ``` {% endtab %} {% endtabs %} ## Supported payment methods A wide variety of payment methods are available. For a complete list, refer to the [Supported payment methods](#supported-payment-methods) page. ## Characteristics of payment methods The following sections explain the methods for charging a payment method and how a customer experiences the payment process. ### Pull or push 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](/commerce-api/payments/payments-solutions/digitalriver.js/payment-methods/credit-cards.md) 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](/commerce-api/payments/payments-solutions/digitalriver.js/payment-methods/wire-transfer.md) 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. ### Synchronous or asynchronous With synchronous payment methods, the [`state` ](#source-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. ### Reusable or single-use You can use some [payment methods](#supported-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](#supported-payment-methods) can only create single-use sources. {% hint style="success" %} Refer to the [Supported payment methods](#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. {% endhint %} 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](https://docs.digitalriver.com/commerce-api-references/commerce-api-reference-guide/api-structure/api-keys#public-keys). So both [Drop-in payments](/commerce-api/payments/payments-solutions/drop-in.md) and [DigitalRiver.js with elements](/commerce-api/payments/payments-solutions/digitalriver.js.md) 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](/commerce-api/payments/sources.md#attaching-a-payment-method-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 reusability, we [block it from being saved to a customer](/commerce-api/payments/sources/using-the-source-identifier.md#restrictions-on-saving-sources). So, you should only [attach it to a cart](/commerce-api/payments/sources.md#attaching-a-payment-method-to-an-order-or-cart) with a non-reusable source. When you convert the cart to an order, this will generate a one-time charge authorization. #### Attaching a payment method to an order or cart The following example shows how to attach a payment method to an order or cart. {% tabs %} {% tab title="POST /v1/shoppers/me/carts/active/apply-payment-method" %} ```json { "paymentMethod": { "sourceId": "e7ba0595-059c-460c-bad8-2812123b9313" } } ``` {% endtab %} {% endtabs %} #### Attaching a payment method to a customer or payment option The Commerce API allows you to save payment sources associated with a customer for later reuse. After you [submit a customer's payment details](/commerce-api/resources/reference/digitalriver-object.md#creating-an-instance-of-drop-in), DigitalRiver.js will create a Source and return a `sourceId`. You can then use that `sourceId` to [attach the source to a payment option](https://docs.digitalriver.com/commerce-api-references/shopper-apis/shoppers/payment-options#v1-shoppers-me-payment-options-1). The following examples show how to attach a payment method to a customer or payment option. {% hint style="warning" %} You can only attach payment methods that [support recurring payments](/commerce-api/payments/supported-payment-methods.md). Note that `storeCredit` does not support recurring payments, so you cannot attach it as a payment option. {% endhint %} {% tabs %} {% tab title="Attaching source to a customer" %} 
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"
  }
}
{% endtab %} {% tab title="Attaching a source to a payment option" %} ```json curl --location --request POST 'https://<>/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" } }' ``` {% endtab %} {% endtabs %} {% hint style="warning" %} You should only attach a Source whose underlying payment method [supports reusability](#reusable-or-single-use). Otherwise, the `reusable` value remains `false` , and the customer can't apply that Source to future orders. {% endhint %} ### Primary or secondary Refer to [primary and secondary sources](/commerce-api/payments/sources/using-the-source-identifier.md#primary-versus-secondary-sources). ### Authentication flow A source's `flow` attribute represents how your customers experience the payment process and what actions they must take to authenticate a [payment method](#supported-payment-methods). 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 immediately * `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 [these guidelines](/commerce-api/payments/building-your-workflows/handling-redirect-payment-methods.md) 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. ## Source state 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](/commerce-api/payments/sources.md#reusable-or-single-use) switches to `consumed` , and no additional charges can be created from the Source. [Reusable sources](#reusable-or-single-use), however, can maintain a `chargeable` state. Sources with a redirect [authentication payment flow](#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](#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](/commerce-api/payments/testing-scenarios.md) to determine whether your integration returns the expected `state` value. ## Source amount 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.digitalriver.com/commerce-api/payments/sources.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.