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_name | verification_status |
|---|---|
| DEFAULT | verified |
| "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_name | ACH Return Code | Description |
|---|---|---|
| DEFAULT | - | NONE |
| "RETURN_NSF" | R01 | Not-sufficient funds in recipient account |
| "RETURN_ACCOUNT_CLOSED" | R02 | Recipient account has been closed |
| "RETURN_STOP_PAYMENT" | R08 | Recipient has requested a stop payment on this transfer |
| "RETURN_UNAUTH" | R29 | Recipient has reported the transaction as unauthorized |