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.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
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:payvault-tokenization
Sandbox Testing
When testing in the sandbox environment, use the following test card numbers to simulate successful card tokenization: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 inexternalProviderSessionData 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 acardDetails 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 includesexternalProviderSessionData with the payment session fields needed to mount the card capture component.
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).
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: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 anappearance object when initializing the component:
Step 3: Create an Exchange in Dwolla
Server-side When the customer submits their card, Flow’sonPaymentCompleted 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
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 fromcardDetails.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
object
required
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. Whenidentification is present, all three of its child fields (type, number, and country) are required.
Request and Response
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.Update Errors
No Fields Provided
No Fields Provided
An update request must contain at least one updateable field.Resolution: Include
name, cardDetails, or both in the request body.Bank Fields Sent to a Card
Bank Fields Sent to a Card
Bank-specific fields are not valid on a card funding source.Resolution: Remove the bank fields and send only
name and cardDetails.Invalid Identity Field
Invalid Identity Field
countryOfBirth and identification.country must each be exactly two characters, and dateOfBirth must be a valid date in YYYY-MM-DD format.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 withremoved set to true. Once removed, the card can no longer receive Push to Card payouts.
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
Invalid Token (Exchange)
Invalid Token (Exchange)
Returned when creating an Exchange (Step 3) if the
token provided is invalid or malformed.Unsupported Country
Unsupported Country
Returned when the card’s issuing country is not supported for Push to Card. Only US-based cards are supported.
Maximum Number of Cards Exceeded
Maximum Number of Cards Exceeded
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.
Missing Required Fields
Missing Required Fields
Returned when required fields are missing from the Exchange or funding source request.