Developers

Current state

Dates are not published until they are confirmed: an announced date becomes a commitment.

What the API allows

The list below describes the scope of the interface, not its current readiness: the state of each component is in the table above.

• Create P2P transactions
• Retrieve transaction statuses
• Manage the transaction lifecycle
• Receive notifications through webhooks
• Run reconciliation of transactions
• Work with available payment directions

Integration path

1. 01

   Get access

   Submit a request for access to the MONTRA infrastructure.

2. 02

   Integrate the API

   Carry out the integration following the API documentation.

3. 03

   Test the scenario

   Verify the payment scenario in the test environment.

4. 04

   Complete the procedures

   Complete the required verification and documentation procedures for onboarding.

5. 05

   Go live

   Launch P2P transfers under the terms of the partner agreement.

Principles the interface is built on

These are not marketing lines: the specification is written from them, and departing from any one of them counts as a change, not an implementation detail.

1. REST over HTTPS, JSON

   No home-grown protocol. HTTP methods, status codes and JSON are used with their conventional meaning rather than as decoration.

2. Idempotency of a repeated request

   Every state-changing request carries an idempotency key generated by the partner. If the connection drops and the request is sent again, no second transaction is created — the result of the first one is returned.

3. Signed webhooks

   Every notification is signed, and the receiving side can verify the signature instead of trusting the source. Delivery is retried until acknowledged, so the receiver must be ready to see the same notification more than once.

4. Meaningful error codes

   An error comes back with a machine-readable code, a human-readable description, and a flag telling whether retrying makes sense. There will be no “error” responses carrying HTTP 200.

5. A separate test environment

   An isolated contour with its own keys and no real money. Integrations are verified there before production access is granted.

6. Versioning and backward compatibility

   A breaking change ships as a new version; the previous one keeps working for a period announced in advance.

{
  "error": {
    "code": "…",        // machine-readable code
    "message": "…",     // description for a human
    "retriable": false  // is a retry worth trying
  }
}

What is not on this page, and why

• No base URL and no working endpoints — they are not published until the contract is fixed.
• No access keys and no test data — issued when the sandbox opens.
• No SDKs or ready-made libraries — not built while the specification is still moving.
• No dates — only a confirmed date gets published.

When the sandbox opens

We run no mailing list and collect no addresses. If you want to know when the sandbox opens, write to us and we will tell you once it is ready.

Write to us: info@montra.kg

P2P Payments · For participants · Security