Skip to main content
POST
OTP / PIN / 3DS step

Authorizations

X-AptaPay-Signature
string
header
required

v1={hex HMAC-SHA256} over the ten-field canonical string. Sent alongside X-AptaPay-Key, X-AptaPay-Timestamp and X-AptaPay-Nonce — all four are required. OpenAPI can only model one header per scheme, so the other three are described in the Authentication section above.

Path Parameters

reference
string
required

Body

application/json
authorization
object

The provider-agnostic envelope. Branch on the next_action.type you were given and post the matching payload back — the wrapper is the same on every rail.

source
object

REQUIRED for a momo authorize — the payer, resupplied. Its last 4 digits must match the transaction.

otp
object

Legacy unwrapped form. Still accepted.

pin
string

Response

The code was accepted and the charge placed. pending means the customer now has the handset PIN prompt; watch the webhook.

The single response envelope, used by EVERY endpoint so a consuming app parses one shape everywhere.

code
integer
required
Example:

200

message
string
required
Example:

"OK"

data
any

Present on success. Shape varies per endpoint.

error
object

Machine-readable error classification. EXACTLY ONE of terminal/retriable/ ambiguous is true. laces_api inferred this from the HTTP status and got it wrong, stranding real money twice (2026-08-15, 2026-08-16). Branch on these booleans, never on the status code:

terminal -> the provider refused. Reverse the debit and tell the user. retriable -> safe to retry with the SAME Idempotency-Key. ambiguous -> the outcome is UNKNOWN. Do NOT reverse. Poll instead.