Sandbox and Testing

Our API sandbox is built to look and feel like the real thing. Every route is sandboxed and data persists exactly like in production. Our goal is to allow you to simulate everything that you'll experience in production in our sandbox. Your data and transactions hold state and go through the same settlement flows as they would in our production environment. Because of this data isolation, your data is not transferable between sandbox and production.

We want the sandbox to be as feature complete as possible. Let us know if you hit snags or wish it had a certain feature - we want to hear it all!

To access the sandbox, you'll use api.column.com as the domain, just like in production - the only differentiator is your sandbox api key. It's prefixed with test-, whereas your production key is prefixed with prod-. You add entities, accounts, and transfers just like you would in your production environment. However, you can also initiate specific behaviors through a couple extra APIs and magic values.

Entities

Entities created in the sandbox environment are auto-approved through our KYC or KYB flow by default, resulting in a "verification_status" of "verified". To simulate a different verification_status, you can set the "last_name" or "business_name" on the entity to the following.

last_name or business_nameverification_status
DEFAULTverified
"Review"manual_review
"Denied"denied

Bank Accounts and Account Numbers

Bank accounts and account numbers work exactly the same in the sandbox as in production. You can send and receive transfers with the same API using the sandbox key.

Initial Balance

All accounts start with a $0 balance. We recommend while you're exploring around to simulate sending a wire transfer into the account. Our sandbox respects the operating hours of the Federal Reserve, just like in production. If you're sending this wire during the weekends or at night, you can make a request to /simulate/transfers/wire/settle or click the instant settle button in the dashboard. Once funds land, you can test book transfers and outgoing transfers. You can do this in the dashboard or over the API.

Incoming transfers

To simulate an incoming transfer, or just to set an initial balance on your account, you can use the /simulate/receive-wire endpoint. To simulate incoming ACH's, we have a /simulate/receive-ach-credit and a /simulate/receive-ach-debit endpoint.

Currently, there's a max of 1 minute delay before the transfer created by /simulate/receive-* endpoints will be created to simulate the delay that'll happen in live environment when interacting with FED.

Outgoing transfers

By default, all outgoing transfers will succeed. This means that wire messages will be submitted without a failure.

By default, all outgoing transfers will settle exactly as they would in production. This means that ACH and wires will respect the hours of the Federal Reserve even in our sandbox environment.

In order to bypass the actual schedule of the Federal Reserve, we offer these endpoints: /simulate/transfers/wire/settle and ​/simulate​/transfers​/ach​/settle. Calling them will settle any outgoing transfer immediately, move funds, and set the transfer to the terminal success state.

ACH Return Codes

We're working to expand this to every ACH return code.

ACH Returns

We offer the ability to simulate a return on an outgoing ACH. In order to do this, you can set the "receiver_name" field on an outgoing ACH to the following:

receiver_nameACH Return CodeDescription
DEFAULT-NONE
"RETURN_NSF"R01Not-sufficient funds in recipient account
"RETURN_ACCOUNT_CLOSED"R02Recipient account has been closed
"RETURN_STOP_PAYMENT"R08Recipient has requested a stop payment on this transfer
"RETURN_UNAUTH"R29Recipient has reported the transaction as unauthorized