Skip to main content

Overview

Adding a debit card as a funding source enables your Customers to receive instant payouts via Push to Card. This guide walks through the complete integration process, combining a client-side card capture experience with server-side API calls to Dwolla. Unlike bank account funding sources, debit card integration requires a client-side component to securely capture card details. The card capture component provides a pre-built, PCI-compliant UI that handles card tokenization, removing the need for your application to directly handle sensitive card data.
Push to Card is a premium feature available for Dwolla customers. Enabling Push to Card requires additional Dwolla approvals before getting started. Please contact Sales or your Relationship Manager for more information.

Integration Flow

The complete flow for adding a debit card involves four key steps:
1

Create and Retrieve an Exchange Session

Create an exchange-session resource via the Dwolla API, then retrieve the exchange-session. The response includes payment session details in externalProviderSessionData that you use to initialize the Flow component. Optionally opt into an Account Name Inquiry here to have the cardholder name checked against the card issuer’s records.
2

Mount the Card Capture Component

Load the Flow UI on your client-side application using the payment session data from the exchange-session response. When the customer submits their card, Flow’s onPaymentCompleted callback returns a payment ID (pay_xxx).
3

Create an Exchange in Dwolla

Create an Exchange resource in Dwolla using the payment ID (pay_xxx) from Flow as the token. The Exchange links the card to your Customer.
4

Create a Funding Source in Dwolla

Create a funding source for your Customer by linking to the Exchange created in the previous step, plus a name and cardDetails (cardholder name and billing address). You can also supply optional cardholder identity fields here to reduce sanctions screening alerts.

Sequence Diagram

The following diagram illustrates the complete sequence of interactions between your client, your server, and the Dwolla API:

Before You Begin

Before integrating debit card functionality, ensure you have:
  • A Dwolla Sandbox or Production account with Push to Card enabled
  • A Checkout.com sandbox account with a public key and push to card enabled
  • An existing Customer in Dwolla who will receive the card funding source
Check out our Push to Card sample application for a complete working example of this integration flow.

Supported Card Types

Push to Card supports debit cards issued by the following card networks:
Only debit cards are supported for Push to Card payouts. Credit cards, prepaid cards, and cards issued outside the United States are not eligible. If an unsupported card is tokenized, the funding source creation will fail with a validation error.

Card Capture API Keys

For this integration, a public key is required. You use it in the browser to initialize the card capture component. Create a public key in the Checkout.com Dashboard with the following scopes:
  • payment-sessions:pay
  • vault-tokenization

Sandbox Testing

When testing in the sandbox environment, use the following test card numbers to simulate successful card tokenization:
For a complete list of test cards and response codes, see the test cards documentation.

Step 1: Create and Retrieve an Exchange Session

Server-side When your Customer is ready to add a card, create an exchange-session resource via the Dwolla API, then retrieve that exchange-session. The response includes payment session details in externalProviderSessionData that you use to initialize the card capture component on the client.
Although Flow uses a payment session, you are not processing a payment. No funds move and your customer is never charged. The payment session is used to securely tokenize your customer’s card. As part of that process, Dwolla’s card processing partner performs a $0 authorization through the card networks to confirm the card is valid and able to receive funds. This is a standard check, not a separate step you need to trigger.

Step 1A: Create an Exchange Session

Create an exchange-session for the Customer. This session will specify the card network exchange partner. The Exchange Partner ID can be found by calling the List Exchange Partners API endpoint.

Optional: Check the Cardholder Name with Account Name Inquiry

Account Name Inquiry (ANI) compares the cardholder name you expect against the name the card issuer has on file. Requesting it gives you an early signal of fraudulent card usage before you create a funding source. To opt in, include a cardDetails object with accountNameInquiry set to true and the name you expect on the card. Dwolla passes that name to the card network during capture and returns the match result on the resulting exchange, which you retrieve in Step 3 as cardDetails.accountNameInquiry. ANI is optional. If you omit cardDetails, the card capture flow behaves exactly as shown above.

Step 1B: Retrieve the Exchange Session

Send a GET request to the exchange-session URL to retrieve the session. The response includes externalProviderSessionData with the payment session fields needed to mount the card capture component.
Use the externalProviderSessionData object as the payment session when initializing Flow: pass id, payment_session_secret, and payment_session_token to your client so it can mount the card capture component (Step 2).
Storing card details requires explicit customer consent. Your application must collect and record this consent before initiating the card capture flow. The consent collection must happen outside of the card capture component.

Step 2: Mount the Card Capture Component

Client-side With the payment session data from the exchange-session response (Step 1), you can initialize and mount the card capture component on your frontend. It provides a secure, pre-built UI for capturing card details without handling sensitive data directly. When your customer submits their card, the component tokenizes it and a $0 authorization is performed through the card networks to validate the card. Both happen automatically, so there is nothing for you to trigger.

Install the Library

Install the card capture library via npm:
Alternatively, load the package directly via a script tag:
To remain PCI compliant, only load the script directly from https://checkout-web-components.checkout.com. Do not download, host, or bundle the script yourself.

Initialize and Mount Flow

Create a container element in your HTML and initialize the Flow component with your payment session:

Configuration Options

Customizing Flow Appearance

The Flow component can be customized to match your application’s branding. You can configure colors, fonts, and border styles by passing an appearance object when initializing the component:
For complete customization options, see the Flow Customization documentation.

Step 3: Create an Exchange in Dwolla

Server-side When the customer submits their card, Flow’s onPaymentCompleted callback returns the payment ID (pay_xxx). Send this payment ID to your server and use it as the token when creating the Exchange.

Request Parameters

Request and Response

Save the Exchange URL from the Location header. You’ll pass this as _links.exchange.href when creating the funding source in Step 4.

Retrieve the ANI Result

If you requested an Account Name Inquiry in Step 1A, send a GET request to the Exchange URL to read the name-match result from cardDetails.accountNameInquiry. Check this value before creating the funding source so you can stop a card that the issuer does not associate with your Customer.
accountNameInquiry returns one of the following values:
Dwolla returns these values in hyphenated form (full-match), which differs from the underscored form the card network uses internally. Match on the hyphenated values.
ANI is informational. A result other than full-match does not block you from creating the funding source, and cardDetails is absent entirely when ANI was not requested. Decide in your own application how to treat each result.

Step 4: Create a Funding Source in Dwolla

Server-side With the Exchange URL from Step 3, create a card funding source for your Customer by linking to that Exchange and providing a name and cardDetails (cardholder firstName, lastName, and billing address). For complete API details, see Create a funding source for a customer. cardDetails also accepts three optional identity fields about the cardholder: dateOfBirth, countryOfBirth, and identification. Supplying them reduces the number of sanctions screening alerts raised when the card is registered and processed, because they give the screening engine enough context to tell your cardholder apart from a similarly named person and clear matches automatically. Fewer alerts means less manual compliance review and fewer delayed payouts. See Cardholder identity fields below.

Request Parameters

Exchange resource to link for the card funding source.
string
required
Arbitrary nickname for the funding source (max 50 characters).
object
required
Cardholder name and billing address.

Cardholder Identity Fields

All three identity fields are optional and independent — send any combination of them, or none at all. Omitting them does not prevent you from creating a card funding source. If you don’t have the values at card capture time, you can add them later by updating the card funding source. When identification is present, all three of its child fields (type, number, and country) are required.

Request and Response

When the funding source is successfully created, you’ll receive a 201 Created response with the Location header containing the URL of the new card funding source.

Retrieve the Card Funding Source

After creating the card funding source, you can retrieve it to confirm the details and verify its status:
dateOfBirth and countryOfBirth appear only if you supplied them. The identification object is write-only and is never returned.
Card funding sources are created with a verified status and are immediately eligible to receive Push to Card payouts. The card was already validated by the $0 authorization that ran during card capture in Step 2, so unlike bank funding sources, there is no separate verification step for you to trigger.

Updating a Card Funding Source

To update a card funding source, send a POST request to the funding source URL with only the fields you want to change. This is how you add the optional cardholder identity fields to a card that already exists, or correct values you sent earlier. Every field is optional, but you must provide at least one. Fields you omit keep their current values.
Card funding sources cannot be updated with bank fields. Sending routingNumber, accountNumber, bankAccountType, or bankAccountHolderType to a card funding source returns a validation error.

Update Errors

An update request must contain at least one updateable field.
Resolution: Include name, cardDetails, or both in the request body.
Bank-specific fields are not valid on a card funding source.
Resolution: Remove the bank fields and send only name and cardDetails.
countryOfBirth and identification.country must each be exactly two characters, and dateOfBirth must be a valid date in YYYY-MM-DD format.
Resolution: Send a two-letter ISO country code, such as US, and format dates as YYYY-MM-DD.

Removing a Card Funding Source

To remove a card funding source, send a POST request to the funding source URL with removed set to true. Once removed, the card can no longer receive Push to Card payouts.
When a card is removed, a customer_card_funding_source_removed webhook is triggered. For more information on webhook events, see Webhook Events.

Handling Errors

When creating an Exchange (Step 3) or a card funding source (Step 4), the Dwolla API may return validation errors. Handle these errors gracefully in your application.

Common Error Responses

Returned when creating an Exchange (Step 3) if the token provided is invalid or malformed.
Returned when the card’s issuing country is not supported for Push to Card. Only US-based cards are supported.
Returned when the Customer has reached the maximum number of allowed card funding sources. The default maximum is 2 cards per Customer, but this limit can be increased if needed.
Returned when required fields are missing from the Exchange or funding source request.

Next Steps

Now that you’ve added a debit card as a funding source, you’re ready to initiate Push to Card payouts.

Understanding Push to Card

Initiating a Push to Card Transfer