Throughout this document and the Velo platform the following terms are used:

• Partner. An organization integrating with Velo to onboard and serve its own customers. Your API credential is scoped to your account: you can only ever read or write customers you created.
• Customer / Payor. A customer you onboard. Each customer is represented as a payor in the Velo platform, linked beneath your account.
• KYC Profile. The verification record attached to a customer - agreements, submitted identity, and verification status. A customer must pass verification before their accounts are activated.
• Source Account. Where a customer's funds are held on the platform. Balances, funding and trading all operate against source accounts.
• Funding. Money coming into a source account from outside the platform - for example an ACH funding request, or a transfer referencing a transaction short code.
• Sandbox. An integration environment which offers the same API experience as production, with simulated funding, verification and screening.

This document describes the Velo APIs a partner uses to run a complete customer lifecycle over the API, with no Velo-hosted UI required:

1. Create the customer - POST /v2/payors with your own reference (payorXid), their address and identity. The create is idempotent on your reference: replaying it returns the customer you already created.
2. Record terms acceptance - one call per contract via the KYC agreements endpoint.
3. Check readiness and submit for verification - readiness answers "can this be submitted yet?" and lists anything missing; submit starts verification.
4. Upload documents when asked - the documents endpoint links a document to your customer and returns a presigned upload URL; file bytes go directly to storage.
5. Track status - poll the customer's payor record and KYC profile, or register a webhook on each customer to be notified of changes.
6. Invite the customer (optional) - create their portal login once they are approved.
7. Fund and operate - read source accounts and balances, create attributable funding transactions, and review funding history.
8. Trade - quote and execute currency trades between a customer's source accounts, with itemized fees disclosed on every quote.
9. Withdraw - register a verified destination (the customer's own bank account or wallet), then move their funds out of the platform with a self transfer.

This is a working integration document prepared for partner hand-off and is not the general Velo Payments API reference.

The Velo Payments API is REST based and uses the JSON format for requests and responses.

Most calls are secured using OAuth 2 security and require a valid authentication access token for successful operation. See the Authentication section for details.

Where a dynamic value is required in the examples below, the {token} format is used, suggesting that the caller needs to supply the appropriate value of the token in question (without including the { or } characters).

Where curl examples are given, the –d @filename.json approach is used, indicating that the request body should be placed into a file named filename.json in the current directory. Each of the curl examples in this document should be considered a single line on the command-line, regardless of how they appear in print.

Once Velo backoffice staff have added your organization as a payor within the Velo platform sandbox, they will create you a payor Id, an API key and an API secret and share these with you in a secure manner.

You will need to use these values to authenticate with the Velo platform in order to gain access to the APIs. The steps to take are explained in the following:

create a string comprising the API key (e.g. 44a9537d-d55d-4b47-8082-14061c2bcdd8) and API secret (e.g. c396b26b-137a-44fd-87f5-34631f8fd529) with a colon between them. E.g. 44a9537d-d55d-4b47-8082-14061c2bcdd8:c396b26b-137a-44fd-87f5-34631f8fd529

base64 encode this string. E.g.: NDRhOTUzN2QtZDU1ZC00YjQ3LTgwODItMTQwNjFjMmJjZGQ4OmMzOTZiMjZiLTEzN2EtNDRmZC04N2Y1LTM0NjMxZjhmZDUyOQ==

create an HTTP Authorization header with the value set to e.g. Basic NDRhOTUzN2QtZDU1ZC00YjQ3LTgwODItMTQwNjFjMmJjZGQ4OmMzOTZiMjZiLTEzN2EtNDRmZC04N2Y1LTM0NjMxZjhmZDUyOQ==

perform the Velo authentication REST call using the HTTP header created above e.g. via curl:

  curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic NDRhOTUzN2QtZDU1ZC00YjQ3LTgwODItMTQwNjFjMmJjZGQ4OmMzOTZiMjZiLTEzN2EtNDRmZC04N2Y1LTM0NjMxZjhmZDUyOQ==" \
  'https://api.sandbox.velopayments.com/v1/authenticate?grant_type=client_credentials'

If successful, this call will result in a 200 HTTP status code and a response body such as:

  {
    "access_token":"19f6bafd-93fd-4747-b229-00507bbc991f",
    "token_type":"bearer",
    "expires_in":1799,
    "scope":"..."
  }

Following successful authentication, the value of the access_token field in the response (indicated in green above) should then be presented with all subsequent API calls to allow the Velo platform to validate that the caller is authenticated.

This is achieved by setting the HTTP Authorization header with the value set to e.g. Bearer 19f6bafd-93fd-4747-b229-00507bbc991f such as the curl example below:

  -H "Authorization: Bearer 19f6bafd-93fd-4747-b229-00507bbc991f "

If you make other Velo API calls which require authorization but the Authorization header is missing or invalid then you will get a 401 HTTP status response.

Following is a list of Http Status codes that could be returned by the platform

| Status Code            | Description                                                                          |
| -----------------------| -------------------------------------------------------------------------------------|
| 200 OK                 | The request was successfully processed and usually returns a json response           |
| 201 Created            | A resource was created and a Location header is returned linking to the new resource |
| 202 Accepted           | The request has been accepted for processing                                         |
| 204 No Content         | The request has been processed and there is no response (usually deletes and updates)|
| 400 Bad Request        | The request is invalid and should be fixed before retrying                           |
| 401 Unauthorized       | Authentication has failed, usually means the token has expired                       |
| 403 Forbidden          | The user does not have permissions for the request                                   |
| 404 Not Found          | The resource was not found                                                           |
| 409 Conflict           | The resource already exists and there is a conflict                                  |
| 429 Too Many Requests  | The user has submitted too many requests in a given amount of time                   |
| 5xx Server Error       | Platform internal error (should rarely happen)                                       |

A Payor is the entity which is sending money. Here you will find the available APIs for working with Payors.

The verification lifecycle of a payor - agreements, readiness, submission and status.

Upload verification documents for a partner's customer.

Payors that are part of the same organization can be linked together in a hierarchical fashion

Your master account sits above every customer you create - your credential reads and writes on their behalf, and GET /v1/payorLinks lists the tree.

Payors can not access data of payors above them in the hierarchy

Contact Velo if you need to link payors in your organization

APIs for initiating funding of source accounts from external sources and viewing balance updates