Nexa endpoints exposed to Tesser

Endpoints Banco Nexa hosts and Tesser calls, for the Tesser x Banco Nexa USDC-to-GTQ offramp POC.

Scope of this integration. Nexa always pays one fixed beneficiary, agreed out-of-band and never present in an API payload: the payout partner that performs the last-mile payout to the individual remittance receivers. Nexa is not involved in the last mile in this phase, so there are no per-recipient beneficiary details anywhere in this contract. Nexa taking on last-mile remittance payouts is a later stage of the programme and out of scope here. The GTQ payout itself is synchronous: POST /v1/payments performs it and returns the outcome.

Auth on every call: Tesser presents its client certificate (mTLS) and Authorization: Bearer <customer_api_key>. The certificate identifies Tesser as the orchestrator, the key identifies the customer context, and the customer field cross-checks it.

Money amounts are JSON strings, decimal, no exponent notation (^[0-9]+(\.[0-9]+)?$): GTQ at most 2 decimal places, USDC at most 6, usdc_gtq_price at most 6. Never JSON numbers. Nexa computes and returns every derived amount; Tesser never derives an amount from the price locally. Timestamps are RFC 3339 UTC. Every POST is idempotent on its natural key: a retry returns the resource's current state, a conflicting body returns 409.

The stub server returns these documents' own canonical examples. An id ending dead (for example 9b2f6c1e-0000-4000-8000-00000000dead) makes a stub return that operation's primary error instead.