Instant Disbursements

Account to Card Transfers

What are Instant Disbursements?

Astra’s Instant Disbursements is a Push-to-Card / Account-to-Card solution that enables your users to create instant “push” payments to an external debit card, with real time settlement and a scalable cost structure. Additionally, you can optionally apply programmatic fees to the payment to create a new source of revenue for your business. Instant Disbursements can be me-to-me or peer-to-peer. With just a couple of taps in your product, an end-user can authorize your product for faster payments, link their debit card, and initiate an instant disbursement.

The technical implementation involves a simple SDK and just a few API requests to start initiating payments. Behind the scenes, the Astra platform confirms that the outbound ACH credit from the end-user’s bank account has been initiated then pre-funds and processes an Original Credit Transaction (OCT) directly onto the debit card with immediate availability of funds.

Step 01: ACH Credits

Astra’s Instant Disbursements payment solution requires an ACH credit from the end-user’s bank account or the client’s operational / business account to be initiated prior to Astra pre-funding and processing an Original Credit Transaction (OCT) directly onto the end-user's debit card.


Note: If you are partnered with Unit, this is all handled for you. For all non-Unit customers, you’ll need to set up and initiate ACH Credits to Astra through your BaaS. Read here to learn more: Unit's Push to Card Payments

Astra must be able to retrieve the ACH Credit from your system via an API request (GET ACH Credit). The ACH Credit must be retrievable by the following:

  • Lookup by unique identifier (e.g. /payments/{id}
  • Lookup by addenda (e.g. /payments?addenda={addenda})
  • Lookup by trace number (e.g. /payments?traceNumber={traceNumber})

The GET ACH Credit endpoint response should include the following:

  • Addenda:
    • Type: String
    • Description: A unique identifier that allows Astra to correlate the payment across the ACH Network and Partner. This identifier is likely to show up in the description of the payment on the end user's bank statement.
  • Trace Number:
    • Type: String
    • Description: Provided by your payment processor (i.e. Synapse), once your payment has been submitted to the ACH Network. Please see your payment processor’s documentation for more details.
  • Amount:
    • Type: Float, Integer, or String
    • Description: the amount of the transaction
  • Status:
    • Type: String
    • Description: field defined by your payment processor (i.e. Synapse).
  • Type of Payment
    • Type: String
    • Description: ACH Credit
  • ACH Credit Destination:
    • Type: String
    • Description: The FBO Account Number


Astra will support whichever authentication method your team chooses. Basic Authentication using a User Name / Password combination is acceptable.


In the event your BaaS doesn’t provide or expose a Trace Number, the ACH addenda will be sufficient.


Astra will provide you with an FBO account and routing number for your Sandbox and Production clients.


Astra will need to test and integrate your GET ACH Credit endpoint during the Sandbox and Production integration phase. You must provide Astra with documentation of your GET ACH Credit endpoint. Astra will need to know the URL, how to request the ACH Credit, and how to authenticate and authorize with your business’s API to make a request. Once documentation is provided, please proceed with Step 02.


Your GET ACH Credit endpoint documentation must include enumerations of all the possible values Astra may receive regarding the status of the ACH Credit. In addition, please highlight which status indicates a canceled ACH Credit.

Step 02: Create Users, Authorize, and Connect External Debit Cards

In order for your Astra Client to be enabled for the account-to-card payment flow, please reach out to the Astra Support Team.

Astra’s Instant Disbursement solution entails instantly sending funds to an end-user’s debit card. Before an Instant Disbursement transfer can be initiated, the end-user will need to be registered, authorized, and have connected an external debit to send funds too. Register a User on our platform by way of the Create UserIntent endpoint. Once submitted, send the end-user into our SDK to authorize Astra and your application to make money movements on their behalf. Once authorized, the user will be prompted to connect a debit card through our PCI compliant card form. You may also prompt the user to connect a debit card through your own debit card form provided that your organization is PCI compliant or has an integration with a vendor such a VGS or similar. At this point, the end-user is set up and ready to initiate an instant disbursement from their account with your application to their debit card. The steps below outline how to set up your client for Instant Disbursements.

Step 03: Account to Card Routine Sample Request / Response

The following provides a sample request for the Account-to-Card endpoint. Requests to this endpoint may include an optional Idempotency-Key header. The header value can be any string the caller wants to use for idempotency but needs to be less than or equal to 128 characters. Astra suggests UUID4. Note: if you are a Unit Customer, please reference their documentation here, as you’ll need to call their specific endpoint for initiating an Instant Disbursement.


Note: the source account in the following request is your business-owned source account which you must register with Astra by way of the Create Account by Account and Routing Number endpoint, not the FBO account that Astra creates for you.

Request: Endpoint: /v1/routines/account-to-card (POST)

  "name": "A2C Routine ABC123",
  "amount": 12.99,
  "transfer": {
	"type": "ach_credit",
	"processor": "<partner>",
	"id": "123456789",
	"addenda": "H3b98dA09K"

  "source": {
  	"id": "your_source_account_id"
  "destination": {
  	"id": "end_user_card_id",
  	"user_id": "end_user_id"
  "debit_fee_percent": 1.25


debit_fee_percent is the customer-defined fee (separate from Astra's fee). The additive/subtractive nature of the fee is defined by the OAuthClient's debit_fee_calculation_mode. By default this is set to additive and is a more common fee structure.


transfer.type should always be ach_credit for Instant Disbursements.
transfer.processor can be whatever /Astra wants to define there, but it's a constant. We can leave it as "".

📘 is the unique identifier (i.e. primary key) of the ACH Credit record in your system.


transfer.addenda is a unique identifier that allows Astra to correlate the payment across the ACH Network and . This identifier is likely to show up in the description of the payment on the end user's bank statement. This must be between 8 and 80 characters in Astra’s system, but your payment processor may have different guidelines.


The ID is the primary key associated with the payment in your system. The addenda is a character string that allows us to uniquely correlate the payment with an ACH Clearing event (between Astra and our banking partner). During an ACH Clearing event, Astra only has access to the addenda and trace number so we need to be able to look up a payment by one of these.

Additional Requirements

  • Users cannot cancel ACH Credits. Only your client can cancel ACH Credits.
  • Your client must automatically cancel ACH Credits if the Astra Routine or Transfer results in a failure. We recommend subscribing to and ingesting Astra’s Transfer Webhooks to obtain Transfer statuses. In the event of a Debit OCT failure, Astra will not retry the credit to the destination debit card.
  • Fees:
    • Whether a fee is a subtractive or additive, you must clearly display to the User the fees that will be applied and the total amount they’ll be sending or receiving depending on the fee structure.
    • Notify Astra that you plan to apply fees and the date with which you plan to go-live with fees.
      Share the percentage fee amount(s).
    • Provide Astra with a screenshot from your application's user interface, demonstrating how fees are displayed and communicated to the User.