Dwolla Destination

Nexla's bi-directional connectors allow data to flow both to and from any location, making it simple to create a FlexFlow data flow that sends data to a Dwolla location.

Dwolla

Create a Dwolla Destination

1. Click the + icon on the Nexset that will be sent to the Dwolla destination, and select the Send to Destination option from the menu.

2. Select the Dwolla connector from the list of available destination connectors. Then, select the credential that will be used to connect to the Dwolla account, and click Next; or, create a new Dwolla credential for use in this flow.

3. In Nexla, Dwolla destinations can be created using pre-built endpoint templates, which expedite destination setup for common Dwolla API write operations. Each template is designed specifically for the corresponding Dwolla endpoint, making destination configuration easy and efficient.
   • To configure this destination using a template, follow the instructions in Configure Using a Template.

   Dwolla destinations can also be configured manually, allowing you to send data to Dwolla endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
   • To configure this destination manually, follow the instructions in Configure Manually.

Configure Using a Template

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Dwolla API endpoints. Each template is designed specifically for the corresponding Dwolla endpoint, making destination setup easy and efficient.

• To configure this destination using a template, select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.

  Create a funding source for an account

  Creates a new funding source (bank account) linked to an existing Dwolla account. Use this endpoint to programmatically add bank accounts to your Dwolla account for use in payment operations. This is typically used when onboarding new bank accounts for ACH transfers.

  • Ensure the Nexset data contains the required fields for creating a funding source. At minimum, the Dwolla API requires the routing number, account number, bank account type (checking or savings), and a name for the funding source.
  • This endpoint sends a POST request to /funding-sources with the funding source details as a JSON payload. Nexla will send each record in the Nexset as a separate API call.

  For complete details on required and optional fields for creating a funding source, refer to the Dwolla Funding Sources API reference.

  Certify beneficial ownership

  Certifies the beneficial ownership status for a business customer. This is a required compliance step for business verified customers in Dwolla. Use this endpoint after beneficial owner records have been created and verified to complete the business verification process.

  • The endpoint URL includes a Customer ID path parameter. Ensure the Nexset data contains the Customer ID for the business customer whose beneficial ownership is being certified. The Customer ID is used to construct the destination URL in the format:

    • {'/customers/{id}/beneficial-ownership'}
  • The request body should contain the certification status. Dwolla expects a JSON body with a status field set to certified to complete certification.

  Beneficial ownership certification is required for business verified customers under U.S. FinCEN regulations. This step must be completed before the customer can initiate transfers. For complete details, refer to the Dwolla Customers API reference.

  Create a client token

  Creates a short-lived client token for secure client-side interactions with the Dwolla API. Client tokens are used by Dwolla's Drop-in Components and JavaScript library to perform sensitive operations (such as collecting bank account information) directly from the end user's browser without exposing your server-side credentials.

  • Ensure the Nexset data contains the required fields for generating a client token. Dwolla requires an action field specifying the permitted client-side operation (for example, customer.create or customer.update), and optionally a _links object identifying the customer the token applies to.
  • This endpoint sends a POST request to /client-tokens. Client tokens are single-use and expire after a short duration.

  Client tokens are intended for use with Dwolla's front-end components and JavaScript library. For complete details on supported actions and request payload structure, refer to the Dwolla Client Tokens API reference.

  Create a customer

  Creates a new customer record in Dwolla. Customers represent the end users (individuals or businesses) who participate in payment workflows on your platform. Use this endpoint to programmatically onboard new customers as part of your user registration or onboarding flow.

  • The required fields vary depending on the type of customer being created:

    • Unverified customers: Require only firstName, lastName, and email. Unverified customers have lower transfer limits.
    • Verified personal customers: Require additional identity fields including address1, city, state, postalCode, dateOfBirth, and ssn (last 4 digits or full SSN depending on verification needs).
    • Verified business customers: Require business-specific fields including businessName, businessType, ein, and controller information.
  • Ensure the Nexset records include all required fields for the target customer type before sending to this destination.

  Dwolla enforces uniqueness on email addresses for customers. Attempting to create a customer with an email already in use will return an error. For complete details on customer types and required fields, refer to the Dwolla Customers API reference.

  Update a customer

  Updates profile information for an existing Dwolla customer. Use this endpoint to modify customer data such as contact information, or to upgrade a customer from unverified to verified status by providing additional identity verification information.

  • The endpoint URL includes a Customer ID path parameter. Ensure the Nexset data contains the Customer ID of the customer to be updated. The Customer ID is used to construct the destination URL in the format:

    • {'/customers/{id}'}
  • Include only the fields that need to be updated in the request body. The Dwolla API uses a POST method for customer updates (not PATCH), and accepts partial updates.

  Updating a customer to a verified status requires providing complete identity information. The available fields and requirements depend on the customer's current status. For complete details, refer to the Dwolla Customers API reference.

  Update or remove a funding source

  Updates the name of an existing funding source or marks a funding source as removed. Use this endpoint to rename a bank account associated with a Dwolla account, or to deactivate a funding source that is no longer needed.

  • The endpoint URL includes a Funding Source ID path parameter. Ensure the Nexset data contains the Funding Source ID of the funding source to be updated or removed. The Funding Source ID is used to construct the destination URL in the format:

    • {'/funding-sources/{id}'}

  • To update the funding source name, include a name field in the request body with the new name.

  • To remove (deactivate) the funding source, include "removed": true in the request body. Removed funding sources cannot be used for new transfers but their history is preserved.

  Removing a funding source is a permanent action that cannot be reversed. For complete details, refer to the Dwolla Funding Sources API reference.

  Initiate a KBA Session

  Initiates a knowledge-based authentication (KBA) session for a customer as part of the identity verification process. KBA presents the customer with multiple-choice questions derived from credit bureau data to verify their identity without requiring document uploads.

  • The endpoint URL includes a Customer ID path parameter. Ensure the Nexset data contains the Customer ID of the customer for whom the KBA session is being initiated. The Customer ID is used to construct the destination URL in the format:

    • {'/customers/{id}/kba'}
  • No additional fields are required in the request body for initiating a KBA session. The response will contain a KBA session ID and the set of questions for the customer to answer.

  KBA sessions are time-sensitive and must be completed promptly. The KBA session ID returned by this endpoint is used with the "Retrieve KBA Questions" and "Verify KBA Questions" endpoints to complete the verification. For complete details, refer to the Dwolla KBA API reference.

  Verify KBA Questions

  Verifies a customer's answers to KBA questions to complete their identity verification. This is the final step in the KBA verification flow, after a KBA session has been initiated and questions have been retrieved and presented to the customer.

  • The endpoint URL includes a KBA ID path parameter. Ensure the Nexset data contains the KBA ID from the initiated KBA session. The KBA ID is used to construct the destination URL in the format:

    • {'/kba/{kbaId}'}
  • The request body must contain the customer's answers to the KBA questions in the format specified by Dwolla. Each answer is associated with a question ID and the selected answer ID.

  A customer has a limited number of attempts to pass KBA verification. Failure to pass within the allowed attempts will result in the customer requiring an alternative verification method. For complete details, refer to the Dwolla KBA API reference.

  Initiate a Transfer

  Initiates a money transfer between two Dwolla funding sources. This is the core payment operation in Dwolla, enabling ACH bank-to-bank transfers between customers. Use this endpoint to programmatically send or collect funds as part of your payment workflows.

  • The Nexset records must contain the required fields for initiating a transfer:

    • _links.source.href: The URL of the source funding source (the account being debited). Example: https://api.dwolla.com/funding-sources/{source-id}.
    • _links.destination.href: The URL of the destination funding source (the account being credited). Example: https://api.dwolla.com/funding-sources/{destination-id}.
    • amount.value: The transfer amount as a string (for example, "10.00").
    • amount.currency: The currency code (must be "USD" for Dwolla).
  • Optionally, include a correlationId field to tag the transfer with an internal reference identifier for tracking and reconciliation.
  • For Same Day ACH transfers, include "achDetails": {""{""}"clearingCode"": ""SD""}" in the request body.

  Transfers in Dwolla are asynchronous. After initiation, the transfer will move through processing states (pending → processed or failed). Use webhooks or the "Retrieve a Transfer" endpoint to monitor transfer status. For complete details, refer to the Dwolla Transfers API reference.

  Cancel a Transfer

  Cancels a pending transfer before it has been processed. Use this endpoint when a transfer needs to be voided after initiation but before it clears. Only transfers in a pending status can be cancelled.

  • The endpoint URL includes a Transfer ID path parameter. Ensure the Nexset data contains the Transfer ID of the transfer to be cancelled. The Transfer ID is used to construct the destination URL in the format:

    • {'/transfers/{id}'}
  • The request body must contain "status": "cancelled" to indicate that the transfer should be cancelled.

  :::warning Important Transfer cancellation is only available while the transfer is in pending status. Once a transfer moves to processed, it cannot be cancelled and must be reversed with a new transfer in the opposite direction. :::

  For complete details on transfer cancellation and status transitions, refer to the Dwolla Transfers API reference.

Configure Manually

Dwolla destinations can be manually configured to send data to any valid Dwolla API endpoint. Manual configuration is ideal for write operations not covered by the pre-built templates, such as creating beneficial owner records, uploading documents, or interacting with other Dwolla API resources.

Using manual configuration, you can also configure Nexla to automatically send the response received from the Dwolla API after each call to a new Nexla webhook data source.

API Method

1. To manually configure this destination, select the Advanced tab at the top of the configuration screen.

2. Select the API method that will be used for calls to the Dwolla API from the Method pulldown menu. Dwolla uses POST for creating resources and most write operations; it uses PUT for certain update operations. Review the Dwolla API reference for the specific endpoint to determine the correct method.

Data Format

3. Select the format in which the Nexset data will be sent to the Dwolla API from the Content Format pulldown menu. Nexla will automatically convert the data to the selected format for each API call. The Dwolla API accepts and returns JSON (application/json or application/vnd.dwolla.v1.hal+json).

API Endpoint URL

4. Enter the URL of the Dwolla API endpoint to which you want to send the Nexset data in the URL field. This should be the complete URL for the target environment:

   • For Sandbox write operations: https://api-sandbox.dwolla.com/{endpoint_path}
   • For Production write operations: https://api.dwolla.com/{endpoint_path}

   For operations that target a specific resource (such as updating a customer), include the resource ID in the URL path (for example, https://api.dwolla.com/customers/{customer-id}).

Request Headers

Optional

• If Nexla should include any additional request headers in API calls to this destination, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (e.g., header1:value1,header2:value2). For Dwolla, you may specify an Idempotency-Key header to prevent duplicate submissions for the same operation.

  You do not need to include the Authorization header. Nexla automatically includes Bearer token authentication based on your Dwolla credential. Consider using an Idempotency-Key header for transfer creation to prevent duplicate transfers in the event of network issues or retries.

Exclude Attributes from the Call

Optional

• If any record attributes in the Nexset should be omitted when sending data to this Dwolla destination, select the attributes from the Exclude Attributes pulldown menu.

• Any number of attributes can be selected for exclusion, and all excluded attributes will be shown in the field. To remove an attribute from the list, click the X icon next to the attribute name.

Record Batching

Optional

1. If records should be sent to this destination in batched API calls, check the box next to Would you like to batch your records together? to enable record batching.

2. Enter the maximum number of records that should be batched together in a single API call in the Batch Size field. By default, this value is set to 100.

3. Select the algorithm that will be used to group records into batches from the Grouping Algorithm pulldown menu. The sample request shown in the panel on the right will be updated to reflect the current batching settings. Some algorithms require additional settings—click on an algorithm listed below to view instructions for configuring these settings.

Property Inside JSON Object

1. Enter the name of the JSON property that should contain the batched records in the Property Name field.
2. If any additional properties should be included in the request, enter the properties in the Other Props field in JSON format.

Code

1. Enter the code that will be used to create the batched request in the code editor below the Grouping Algorithm field.

Response Webhook

Optional

Nexla can automatically send the response received from the Dwolla API after each call to a new Nexla webhook data source. This option allows you to track the status of each API call and capture any additional information returned, such as the resource URL of a newly created transfer or customer.

• To enable this option, check the box next to Would you like to process the API response as a Nexla Webhook source?.

Sample Request Payload

Sample request payloads containing a portion of the Nexset data that will be sent to the Dwolla API endpoint based on the current settings are shown in the Sample Payload panel on the right. These samples can be referenced to ensure that the destination and request settings are correctly configured.

• Click on a sample request payload to expand it and view the complete payload content.
• Sample payloads are automatically updated with each setting change, making it easy to verify that changes achieve the desired effect.

Endpoint Testing (Manual Configuration)

After all endpoint settings have been configured, Nexla can send a test payload to the Dwolla API to ensure that the destination is configured correctly.

1. To send a test payload, select the Test button at the top of the Sample Payload panel, and click on a listed sample payload to expand it.

2. If any modifications to the sample payload are needed, make the necessary changes directly within the sample window.

3. Click the Send Test Data button at the top of a sample payload to send the test payload to the Dwolla API using the current settings.

Save & Activate the Destination

• Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To begin sending data to the configured Dwolla endpoint, open the destination resource menu, and select Activate.

  The Nexset data will not be sent to the Dwolla API until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.