Source basics
Learn the basics of sources.
Last updated
Learn the basics of sources.
Last updated
A is associated with the customer's that a customer uses to fund a transaction. When generating a charge, Digital River retrieves data from the .
In the Digital River APIs, each has that determine how it's created and how a is eventually processed.
A type represents the used to create that object.
A 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.
A characteristics revolve around the , , , , and .
The difference between a pull and push payment involves how a customer's funds are transferred.
With pull , 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 , 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 on your website or app, you'll need to to complete payment, and they must then "push" the funds.
With synchronous payment methods, the of the resulting is returned immediately as either chargeable or failed. A credit card is an example of this source .
With asynchronous payment methods, the may first return in state of pending_funds, pending_redirect, or requires_action before it transitions to chargeable. For example, a source with a of payPal is asynchronous because the customer is redirected to the site and must take additional action to authorize the transaction.
When integrating asynchronous payment methods, you can to listen for the with a of source.chargeable. This will allow you to determine when to or .
Some can be used to create reusable , meaning they support recurring charge authorizations. In customer-initiated transactions, you can present to customers for convenience. You can also use reusable sources in renewals.
Other only create single-use .
Refer to the 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.
must have a reusable value of true before they can be used to make multiple . Reusable sources can't be created using a . As a result, both and only generate single-use sources. To make them reusable once created (assuming the source's supports reusability), you must . This flips reusable to true and prevents the source's from becoming consumed once it's associated with the .
If a source's underlying payment method doesn't support reusability, we . As a result, with non-reusable sources, you should only . When you , this will generate a one-time charge authorization.
Refer to
A 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 , 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 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 can be created. We recommend you adhere to when using redirect payment methods.
receiver: This flow requires that customers push funds to an account before a can be created. is a common payment method that uses this authentication flow.
A 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 is chargeable. You can listen for source.chargeable to be notified of when the source transitions to this state.
Once charged, the state status of switches to consumed , and no additional charges can be created from the Source. , however, can maintain a chargeable state.
Sources with a of redirect, such as , often are in a state of pending_redirect because the customer must leave your website to confirm the payment.
For sources with a of receiver, such as , it may take days before the funds are confirmed by the receiving bank or financial institution, thereby switching the state from pending_funds to chargeable.
For different success and error scenarios, you can to determine whether your integration returns the expected state.
Once all captures are complete, the customer's payment method is charged the amount value contained within the , considering any or .
Each time that Digital River returns an updated , 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 , the is returned with an updated amount.