Skip to main content
Reverse credit funds
This API MUST be implemented by the Partner. Platform’s backend will request fund reversal in case of an operation error.
Our backend will consume this service by performing a POST request to: [Base-URL]/ReverseCreditFunds.
The path must be respected exactly as specified. The Partner defines only the [Base-URL]; the resource segment /ReverseCreditFunds, the POST method and the JSON body are fixed by this contract and are case-sensitive.Every request travels signed. It carries the X-Timestamp and X-Signature headers with the HMAC-SHA256 signature of the raw body. The Partner must validate the signature before processing the request.
If reversal is not supported, response must be Success: false, indicating the reason in ResponseDescription. Expected behavior: Order for total reversal of a previous credit movement associated with a CreditTrackingNumber. This usually occurs in case of cancellations, failures in the operation chain, or financial readjustments. The Partner must return the funds from the specified account and confirm success by returning Success as true.
A Success: true response MUST carry a TrackingIdentifier. As with Credit Funds, it is the Platform’s only record of the reversal movement and it cannot be recovered afterwards. A successful reversal returned without one leaves the Platform holding a credit it believes was undone but cannot evidence, and the movement has to be reconciled by hand with the Partner.If the reversal cannot be applied, return Success: false with the reason in ResponseDescription; that path does not require a TrackingIdentifier.

Headers

X-Timestamp
string
required

UTC timestamp in ISO-8601 format with milliseconds (yyyy-MM-ddTHH:mm:ss.fffZ), generated at send time. Its exact string value is part of the signed message, so it cannot be altered, and it lets the Partner reject stale requests (replay protection). See Data Integrity.

X-Signature
string
required

HMAC-SHA256 signature of the request, Base64-encoded (standard alphabet). It is computed over bytes(X-Timestamp) + bytes(".") + rawBodyBytes using the shared secret agreed for the integration. The Partner MUST validate it — with a constant-time comparison and over the raw body, before any deserialization — and reject the request if it does not match. See Data Integrity.

User-Agent
string
required

Fixed value VNA. Sent on every request. Some Partners' WAFs reject requests without a User-Agent, so the Platform always sets it explicitly; if the Partner filters by this header, this is the value to allow.

Body

application/json
TransactionId
string
required

Unique identifier of the request, used as an idempotency key. It is derived deterministically from the operation, the Partner and the action, so a retry of the same action arrives with the same value: the Partner MUST process it only once and return the original outcome on repeats.

AccountIdentifier
string
required

An Id representing the External Account Object for the Partner.

CreditTrackingNumber
string
required

The TrackingIdentifier the Partner returned in the Credit Funds response — that is, the identifier of the credit movement being referred to.

Response

200 - application/json

Ok

Success
boolean
required

True if the reversal is Successful / False if the reversal is not supported or Failed.

TrackingIdentifier
string
required

Identifier assigned by the Partner to the reversal movement. Mandatory whenever Success is true — a successful reversal returned without it makes the Platform report the operation as failed even though the funds were already returned.

ResponseDescription
string

If the reversal is not successful, the reason should be indicated in this field.