Leap Financial
External Account Object Integration
VNAAPI Definition
Version 3.6 September 2026
Proprietary Notice
All pages of this document contain information proprietary to Leap Financial Inc. Neither this document nor any information in it shall be duplicated, transmitted, used, or otherwise disclosed to anyone other than the organization or specific individuals to whom this document is delivered. This restriction applies to all sheets of this document. Leap Financial Inc. reserves the right to have the recipient return all copies of this document at any time. Leap Financial Inc. is a technology company that provides financial services by acting as a program manager for a bank through a bank sponsorship. It is also a registered agent for other regulated financial institutions. In this document, we refer to the Program Manager as the “Program” and as “LEAP” and to the Program Sponsor as the “Bank”.Abstract
This document purpose is to define how a partner should integrate with Leap Financial’s External Account Object feature by providing the APIs that Leap Financial will use to Authorize the transactions with the partner and Confirm that the funds of such transactions need to be creditedAudience
This document is provided for the technical teams in charge of developing the APIs for the integration, it is assumed that the audience of this document is familiar with the concepts of API, and technical terms such as request, response and payload.Glossary
Partner = the company implementing the endpoints with the definition provided in this document, that is the owner of the External Account Object. External Account Object = element in Partner’s system that is associated with the transaction executed by Leap Financial Remittance = transaction that is executed to move funds cross borderExternal Account Object Integration Overall Details
In order to be able to execute remittances transactions, Leapfinancial requires the Partner the ability to process an authorization request prior to the execution of the transaction. The Authorization request will be triggered by LeapFinancial system when a user selects that he wants to send funds to another user, and the destination Payment Method is the Partner’s External Account Object. Leap Financial provides the payload structure for the Authorization request as well as the method to be implemented, and the Partner will provide the API endpoints aligned with the definition. When the partner processes the Authorization request, the response needs to be sent to Leap Financial containing the data elements required in the API definition. Upon approval of the Authorization request, Leap Financial will execute the remittance transaction. If the transaction is successful, Leap Financial will inform the Partner that the funds can be credited to the External Account Object in the partner’s systems. Leap Financial provides the payload structure for the Credit Funds request, as well as the method to be implemented, and the Partner will provide the API endpoints aligned with the definition. Leap Financial requires that the Partner provides a confirmation that the funds have been credited to the External Account Object in their system. When the partner confirms the credit funds request, the response needs to be sent to Leap Financial containing the data elements required in the API definition.Authentication for APIs
All requests to the Partner’s endpoints are protected at two independent layers:- Message — HMAC-SHA256 request signing over the
X-Signatureheader, which proves the authenticity and integrity of each payload. Mandatory, and fully specified in Data Integrity. - Channel — TLS on every connection, optionally reinforced with a site-to-site VPN or IP allowlisting at the Partner’s request. Mandatory, and described in Communication Security.
API Definitions
The full contract of each endpoint — request and response fields, types, whether each one is required, possible values, and the reason codes — lives in the Client Interfaces section, generated from the OpenAPI specification so it never drifts from the implementation.Tx Authorization
TxAuthorization — request authorization for a Transaction.Credit Funds
CreditFunds — notify that the funds must be credited to the External Account Object.Reverse Credit Funds
ReverseCreditFunds — request the reversal of a previous credit movement.Get Credit Status
GetCreditStatus — query the status of an asynchronous credit order.Create Account
CreateAccount — create an External Account Object for a Person.Get Create Account Url
GetCreateAccountUrl — obtain a delegated registration URL for a Person.POST method with a JSON body and return Status Code 200. The reason codes returned in NonAuthorizedReason and NonCreditReason, and the possible values of CreditStatus and DocumentType, are documented alongside the field that carries them.
Identifier Chaining
Each endpoint returns an identifier that the next one sends back. The field changes name at every hop, so this is the chain to follow:1
Tx Authorization
The Partner approves the transaction and returns its own
TrackingIdentifier.2
Credit Funds
The Platform sends that value in
AuthTrackingIdentifier so the Partner can tie the credit to the authorization it already approved. The Partner applies the credit and returns a new TrackingIdentifier, this one identifying the credit movement.3
Get Credit Status / Reverse Credit Funds
The Platform sends the credit’s identifier in
CreditTrackingNumber. Both endpoints refer to the same movement — one to read its status, the other to undo it.The three
TrackingIdentifier values are independent and are minted by the Partner: the one from the authorization is not the one from the credit, and neither is the one from the reversal. AuthTrackingIdentifier and CreditTrackingNumber are just the names those values take when they travel back in a request.Idempotency and Retries
Every request carries aTransactionId that acts as an idempotency key: it is derived deterministically from the operation and the action, so a retry of the same action arrives with the exact same value.
The Platform retries on network errors, timeouts and non-2xx responses. The Partner must therefore process each TransactionId only once and return the original outcome on repeats — never apply the credit twice.