Quick Integration

Quick Integration

Note that our system generally requires that you have your senders fully KYC'd for them to be able to transact. Therefore before you start with the implementation please contact our team as they will assess how you'll plan to use our API and what KYC requirements you'll need to have. Also your sandbox API keys are only activated once you'll contact us and we approve you using our test system.

Development should be done on our sandbox environment. Once you finish with the integration we will have a chat to check that your implementation works as expected, and as a minimum supports the following functionalities:

Authenticate to our site Create and fund transactions Check the state of transactions both via webhooks and manually Handling and cancelling failed transactions Once you pass these requirements we'll approve your API and allow it to be used on our production system.

The sandbox environment All development must be conducted within our sandbox environment, which offers a comprehensive testing environment with certain limitations and additional features to aid in testing. We kindly request that you familiarize yourself with these features by referring to our documentation on the sandbox environment.

Creating transactions

Please read our guide on creating transactions on how you can create transactions, and the various options you have. Please make sure you already have discussed with us how your transactions will be funded before you start with this task.

Funding transactions

If you are going to have a balance with us, then please read our guide on funding transactions on how you can fund the transaction. Funding the transaction means you approve the amounts that were returned in the transaction and you are happy for us to initate the payout.

Checking transaction state

Once a transaction is funded you can use our webhook facilities to listen in changes in the transaction state. You should listen to both the transaction and the senders events. On more info about webhooks please see our webhook guide. You should also be able to query transactions manually, but this facility should only be used rarely.

Handling errors

You need to be sure that you can handle transactions where the payout has failed. For a generic guide please see how you receive error messages and how you can cancel transactions. A more in-depth guide as available in our error handling documentation.

Note that by default we will cancel funded transactions if we cannot pay them out within 24 hours.

Although the auto cancellation feature makes it much easier to handle failing transactions on your end, we still require that your system can receive error messages from us, and can cancel these transactions manually as well if required.

Any transaction that is not cancelled - even ones that seemingly have a fatal error in their description could potentially pay out in the future. If you don't wish a transaction to pay out and you'd like to recover the debited funds you HAVE TO cancel the transaction, and then make sure it got cancelled before you update your system.

Re-using senders

Finally you need to be able to re-use senders. This means any time you wish to create a transaction for the same sender you already used, you should use the same external_id. This is so we can tie the transactions made by the same sender together for KYC and AML purposes. For more details please see senders on transactions.