Drop-in payments integration guide
Learn how to integrate Drop-in payments
This page explains how to get started integrating Drop-in payments into both checkout flows and account management flows.
We recommend also using the Drop-in payments builder and the Building payment workflows page to learn how to integrate our supported payment methods into your app or website.
Getting started
Follow these steps to set up Drop-in payments:
Step 1: Include DigitalRiver.js
Include the following script on the pages where you want Drop-in payments to display (for example, on checkout or account management pages):
Step 2: Include the base CSS file
Include the following link to the Drop-in payments CSS file on the same pages. If you'd like to customize styles, override this CSS file with your own.
Step 3: Initialize DigitalRiver.js with your public key
Initialize the DigitalRiver.js library with your public API key. If you provide locale
, then Drop-in payments is localized based on that value.
Step 4: Create a Drop-in payments container
Create a container element on the page where you want Drop-in payments to appear.
Step 5: Create a Drop-in payments configuration object
Create a configuration object. For details, refer to Configuring Drop-in payments.
Step 6: Use the configuration object to create an instance of Drop-in payments
Create an instance of Drop-in payments by passing the configuration object to createDropin()
.
Step 7: Mount Drop-in payments on the checkout or account management page
Add the following statement to the appropriate checkout or account management page:
Once invoked, mount()
displays Drop-in payments in the designated container.
Step 8: Enable the payment method in Digital River Dashboard
Sign in to Dashboard and enable payment methods.
Using Drop-in payments in checkouts
To use Drop-in payments in checkout flows, you'll need to (1) finalize your checkout, (2) configure and mount Drop-in payments, and (3) handle the onSuccess
event.
Finalize the checkout
Before interacting with Drop-in payments, your integration should obtain the customer's billing information and use it to set the checkout's billTo
.
For more details, refer to Billing address requirements on the Providing address information page.
The checkout's totalAmount
should also be finalized. So, when applicable, make sure you've set the checkout's shipFrom
, shipTo
, shippingDiscount
, shippingChoice
, taxIdentifiers[]
and any other data that may affect totalAmount
.
Configure and mount Drop-in payments
Retrieve the checkout's payment.session.id
and use it to set sessionId
in the Drop-in payments' configuration object. In that same object, you should also set:
flow
tocheckout
showComplianceSection
totrue
showTermsOfSaleDisclosure
totrue
Once the create and mount methods are invoked, Drop-in payments open on the experience page that holds the container element. For more details on this process, refer to the Getting started section.
Customers then select how they want to pay.
Depending on which payment method customers select, they may be redirected to a third-party payment authorization site. Drop-in payments handle all these redirects.
Handle the onSuccess
event
onSuccess
eventIf customers supply the required information, click the configurable button, and payment is successfully authorized, you should handle onSuccess
by passing source.id
to your backend and use your secret API key to associate the source with the checkout.
In the following example, the data
object of onSuccess
contains a source
whose state
is chargeable
. Since readyForStorage
is false
, this source can only be used once (i.e., it can't generate multiple charges).
Optional. Allowing customers to save their payment information
During checkout flows, you can also allow customers to save their payment details for use in future transactions by enabling showSavePaymentAgreement
.
This feature ensures that a customer's payment details are collected in a PSD2 and SCA-compliant manner.
When you enable this feature, each displayed reusable payment method is accompanied by a box that customers must check if they want that payment information saved to their account.
If customers check the box and click the configurable button, Drop-in payments perform any required authentications and, assuming that process is successful, the data
object of onSuccess
contains a source that is readyForStorage
.
In this case, handle onSuccess
by passing source.id
to your backend and use your secret API key to associate the source with the customer before you associate the source with the checkout.
Using Drop-in payments in account management settings
Outside of checkout flows, you can use Drop-in payments to collect a customer's payment information and then determine whether the resulting source should be saved to the customer's record. To do this, you'll need to:
Build the configuration object
In the configuration object, set flow
to managePaymentMethods
. This informs Digital River that you're collecting payment information in an account management setting.
In this type of flow
:
Drop-in payments currently support credit cards and the PayPal Billing Agreement. To ensure that customers are only presented with these options, add
creditCard
and/orpayPalBilling
to yourenabledPaymentMethods
list inpaymentMethodConfiguration
.There's no payment session to reference, so you shouldn't define
sessionId
. Instead, you need to pass the billing information you collect from customers inbillingAddress
.If customers are replacing an active subscription's recurring payment method, make sure you set
usage
tosubscription
andshowTermsofSaleDisclosure
totrue
. This prompts Drop-in payments to display a recurring billing agreement and forces customers to accept it.Drop-in payments automatically (a) require customers to agree to save their payment information for use in future transactions, and (b) don't display compliance information. As a result, you don't need to pass
showSavePaymentAgreement
orshowComplianceSection
.
If you set showSavePaymentAgreement
to false
or showComplianceSection
to true
, then Digital River overrides the values you pass.
Create and mount Drop-in payments
Once you invoke the create and mount functions, Drop-in payments open on your designated account management page. For details, refer to the Getting started section.
Customers then select the payment method to add to their account, provide their personal information, and agree to the storage terms. They may also be required to complete SCA, a process handled by Drop-in payments.
Handle onSuccess
onSuccess
If Digital River successfully creates a source, the data
object of onSuccess
contains a source that is readyForStorage
. Handle this event by sending source.id
to your backend and use your secret API key to associate the source with the customer.
Configuring Drop-in payments
The createDropIn()
method requires a configuration object. You can use this object to:
Payment session identifier
The sessionId
references a payment session.
If options.flow
is checkout
, then you should retrieve the checkout's payment.session.id
and use it to set sessionId
. DigitalRiver.js then uses that identifier to look up the payment session and retrieve the customer's billing address that you assigned to the checkout's billTo
.
In checkout flows, Digital River recommends that, before calling createDropin()
, you pass the customer's billing information in the checkout's billTo
. Doing so lets you use the returned tax data to present customers with finalized tax amounts before moving into the payment collection stage.
If you set options.flow
to managePaymentMethods
, then you don't need to pass a sessionId
. But, as a result, you're required to send a customer's billing information in billingAddress
.
Options
The options
object allows you to:
Flow
Use options.flow
to specify a mode of operation.
If you're using Drop-in payments in a checkout flow, set flow
to checkout
(default).
If you're using Drop-in payments in an account management flow, then set flow
to managePaymentMethods
. This setting informs Digital River that you're collecting and saving a customer's payment information for future transactions and doing so outside of a checkout flow.
Show save payment agreement
The options.showSavePaymentAgreement
attribute determines whether customers are given the option to save a selected payment method to their account.
You only need to set this flag when options.flow
is checkout
. If options.flow
is managePaymentMethods
, then the save payment agreement is automatically displayed.
If showSavePaymentAgreement
is true
, and the selected payment method supports reusability, customers are presented with a box that they must check to save the payment method. Digital River displays appropriate localized disclosure statements with this setting and handles any needed SCA.
If set to false
(default), customers are not given the option to save their payment details.
Show compliance section
The options.showComplianceSection
attribute determines whether Drop-in payments display compliance information.
If true
(default), then Drop-in payments display to a selling entity-specific compliance section. The information in this section is localized based on how you initialize DigitalRiver.js.
Making this compliance information available to customers is critical to accessing Digital River's merchant-of-record business model.
If false
, then the compliance section is not displayed.
Customizing the text of the Drop-in button
By setting options.button.type
to any of the following values, you can customize the text of the Drop-in payments button.
These settings don't change the text of the Google Pay and PayPal buttons. For information on styling these buttons, refer to Payment method configurations.
The button's text is localized based on the locale
you pass when initializing DigitalRiver.js.
You also can personalize the text by setting button.type
to custom
and button.buttonText
to the characters you want to display.
Specifying a source's future use
Set options.usage
to indicate how the payment source will likely be used in future transactions. Passing this value increases the probability that payment providers will approve future authorization requests. The accepted values are subscription
, convenience
, and unscheduled
.
subscription
: The source is to be used for recurring transactions, made at regular intervals, for a product or a service.convenience
: This value applies mainly to saved payment sources used for one-off transactions. These are scenarios where customers are typically present during checkout and want to access their payment information quickly. Always select this option if you don't offer subscriptions or don't have unscheduled merchant-initiated transactions.unscheduled
: The source is to be used in unscheduled merchant-initiated transactions. These are contracts that occur on a non-fixed schedule using saved card information. Automatic top-ups are one such example. They occur whenever a customer's balance drops below a pre-defined amount.
Show terms of sale disclosure
The options.showTermsOfSaleDisclosure
attribute determines whether Drop-in payments display the terms of sale to customers.
If set to true
(default), then the terms of sale disclosure are displayed, and customers must accept them.
The terms are localized based on how you initialize DigitalRiver.js.
The terms depend on whether customers make a one-time purchase or buy a subscription product.
If set to false
, no terms of sale are displayed.
Add disclosures
You can use options.consents
to add your end-user license agreement and terms of use to Digital River's disclosures. To make this feature work, showTermsOfSaleDisclosure
must be true
.
If you pass consents
, then companyName
is required. You're not required to provide either eula
or termsOfUse
, but if you do, you must specify a url
that links to the relevant document.
Once you create and mount Drop-in payments, your consents
are appended to Digital River's disclosures.
Disabling redirects
In options
, redirect
allows you to configure how sources with a flow
of redirect
are handled.
It's nested disableAutomaticRedirects
boolean determines who initiates the redirect to the payment provider.
If you want to handle this redirect, then set disableAutomaticRedirects
to true
.
If you do, then returnUrl
and cancelUrl
are required and should be assigned the same value.
With this configuration, if customers select a redirect payment method, then onSuccess
returns a source whose state
is pending_redirect
.
At this point, you can associate the source with the checkout and allow customers to review the transaction's details. If they decide to purchase, create the order and then redirect them to the payment provider's portal.
While there, customers approve or cancel the transfer of funds. Once they complete either of these actions, they're sent to the location you specified in returnUrl
and cancelUrl
. When this resource loads, call a function that triggers a server-side refresh order request and then, in the response, check the order's state
and the payment session's state
. Use these values to determine whether to (1) display the order confirmation page (i.e., the "thank you" page) or (2) recreate the checkout and redo the payment collection stage.
For details, refer to Handling redirect payment methods.
If you want DigitalRiver.js to handle redirecting customers to the payment provider, then set disableAutomaticRedirects
to false
. If you do, returnUrl
and cancelUrl
are optional, and we ignore any values assigned to them.
With this configuration, once customers select a payment method, DigitalRiver.js creates a source, checks its flow
, and then, if it's redirect
, immediately sends customers to the payment provider's portal. If customers approve the transfer of funds and the provider authorizes payment, then onSuccess
returns a source whose state
is chargeable
.
Expand the first payment method
When Drop-in payments loads options.expandFirstPaymentMethod
determines whether the first payment method in the accordion control element is expanded or collapsed.
If expandFirstPaymentMethod
is true
(default) then the first displayed payment method is expanded.
Payment method configurations
The configuration object's paymentMethodConfiguration
allows you to customize payment methods.
Style
Drop-in payments use elements to capture secure payment details. These elements have a predefined style, but you can also customize their look and feel by defining a style
object.
For details, refer to Styling an element container.
Credit card
The creditCard
object allows you to configure how credit cards are displayed.
cardNumberPlaceholderText
: The placeholder that appears in the card number field. If you specify a value, then localization is not applied.cardExpirationPlaceholderText
: The placeholder that appears in the card expiration date field. If you specify a value, then localization is not applied.cardCvvPlacholderText
: The placeholder that appears in the card security code field. If you specify a value, then localization is not applied.style:
For details, refer to Styling an element container.mask
: Indicates whether data entered in the card number and security code fields is automatically masked after successful validation.
Online banking
The onlineBanking
object allows you to configure how the online banking payment method is displayed.
style:
For details, refer to Styling an element container.placeholderText
: The placeholder that appears in the online banking selector.
Google Pay
For details on googlePay.style
, refer to Google Pay element styles and customization.
Apple Pay
For details on applePay.style
, refer to Apple Pay styles and customization.
PayPal
For details on payPal.style
, refer to PayPal element style options.
MSTS
Use msts.enrollmentUrl
to add a link to the TreviPay enrollment URL.
Enable and disable payment methods
Use enabledPaymentMethods
and disabledPaymentMethods
to enable and disable specific payment methods, respectively.
If you don't define either of these lists, then, by default, Drop-in payments display all transaction-applicable payment methods to customers.
If you do define enabledPaymentMethods
, then Drop-in payments only display those that are in this list. However, it's not displayed if your list contains a payment method that doesn't apply to the transaction.
Drop-in payment events
The Drop-in payments' configuration object supports the following events:
onError: Occurs when there's a validation error
onCancel: Occurs when a payment method is cancelled
onReady: Occurs when Drop-in payments are ready to accept input
These events provide real-time updates on the status of payment methods.
onSuccess
onSuccess
If Digital River creates a source, you receive the onSuccess
event.
The event's data
contains the source.
It also contains readyForStorage
and supportsStorage
booleans.
If readyForStorage
is true
then (1) customers approved saving the source to their account and (2) Digital River has performed any required SCA.
A readyForStorage
value of true
doesn't indicate that customers can reuse that same source in future transactions. To accomplish that, you must associate the source with the customer. This request flips the source's reusable
value to true
.
The supportsStorage
value indicates whether the source supports reusability.
If you set showTermsOfSaleDisclosure
to true
, then data
also contains consents
. Its termsOfSale
boolean references Digital River's terms of sale and its eula
and termsOfUse
booleans indicate whether consents
in the configuration object contains a eula.url
and termsOfUse.url
.
When these variables are true
, it signifies customers were presented with that specific disclosure and actively accepted it.
For details on how to handle this event, refer to:
Handle
onSuccess
in the Using Drop-in payments in checkouts section
onError
onError
If an error occurs, you receive the onError
event. The event's data object contains a type
and an array of errors[]
, each of which typically has a code
and a message
.
onCancel
onCancel
You receive the onCancel
event when customers cancel the payment process (e.g., during the redirect phase) before authorizing payment. The event's data
object cancelled the paymentMethod
.
onReady
onReady
You will receive the onReady
event when Drop-in payments are ready to accept input. The event's data
object contains an array that lists all paymentMethodTypes
presented to the customer.
Billing address
You can use billingAddress
to pass a customer's billing information. For details on when to use this object, refer to the Payment session identifier in the Configuring Drop-in payments section.
Last updated