Aller au contenu
ENFR
Obtenir des clés de test

Historique des versions

Le contrat marchand est versionné : la référence de l’API et le client TypeScript généré, que Futa garde pour son propre usage et ne publie pas, suivent sa version actuelle, la première ci-dessous. Chaque version ci-dessous dit, en anglais, ce qui a changé pour qui lit la partie publique /v1, puis liste les opérations, événements de webhook et codes de refus qu’elle a ajoutés à cette partie ou retirés. Les routes du personnel et du portail ne font pas partie de l’API publique : un changement qui ne touche qu’elles n’est pas listé, pas plus qu’une version qui n’a fait que de tels changements.

0.60.15 · 2026-11-04

  • Wording only: the public descriptions, the payout event schemas' among them, say each rule in plain words, without the internal routes, headers, rule numbers and planning ids they named; the sandbox reminder run no longer says it answers 404 ROUTE_NOT_FOUND outside the sandbox, which it never did; no route, schema or code changes

0.60.14 · 2026-11-04

  • Wording only: the API's and the Invoices descriptions say that the merchant portal serves a batch's results workbook and its printable QR sheet; no /v1 route changes

0.60.13 · 2026-11-04

  • The invoice refusal body gains the code REQUEST_INCOMPLETE, which only the merchant portal's file upload answers; no /v1 route answers it

0.60.12 · 2026-11-03

  • Reminders are served, with the sandbox reminder run: a test key runs the reminder schedule as of an instant, each reminder's link replaced before its message, and a message held outside the send window goes at the next opening

0.60.11 · 2026-11-02

  • Wording only: the Invoices description says that a disabled merchant's sends wait, while a file it validates may still be checked against its per-payment limit

0.60.10 · 2026-11-02

  • Adding a chunk and sending a batch declare 503 SWITCH_UNAVAILABLE when the merchant's per-payment limit cannot be read, nothing kept, to be sent again under the same key; a page of invoices read by state may hold fewer invoices than it read, or none, with a next cursor to follow until it is null

0.60.9 · 2026-11-02

  • Adding a chunk says that each amount is judged against the merchant's per-payment limit in force when the chunk arrives

0.60.8 · 2026-11-02

  • A batch's send is served: it answers 202 SENDING, then makes each invoice's link and first messages; a chunk that numbers a line twice is refused 400 INVALID_REQUEST, as it was already

0.60.6 · 2026-11-01

  • The invoice routes are served, but for the send and the sandbox reminder run: a batch's creation, its chunks, its discard and the reads of batches, of a batch's invoices and of an invoice

0.60.5 · 2026-11-01

  • A key an Owner or an Admin issues may hold invoices:read and invoices:write; the invoice routes are not served yet

0.60.4 · 2026-11-01

  • Adding a chunk of invoices, declared and not yet served, states the reference rule an invoice states: a reference stays held while its invoice is ready in a live batch or has a live link, whatever the batch's state

0.60.3 · 2026-11-01

  • The declared invoice routes, which nothing served yet, list a batch's invoices by the CANCELLED state too, count as undelivered only an invoice whose delivery is UNDELIVERED, end NOT_SENT with NOT_REMINDABLE a held message whose invoice can no longer be reminded, and stop the sandbox reminder run's calls at 19:55 Kinshasa on its as_of's day

0.60.2 · 2026-11-01

  • The declared invoice routes, which nothing served yet, say that a batch whose send failed has its invoices read CANCELLED unless paid or being verified, that a reference stays held while its invoice is ready in a live batch or has a live link, that a message mirrors its channel's states with sent_at, that a delivery may be UNCONFIRMED, and that every text is kept as the text rule trims it

0.60.1 · 2026-11-01

  • The declared invoice routes, which nothing served yet, gain the discard of a batch not yet sent, a bound of 20 open batches (INVOICE_BATCH_LIMIT_REACHED, SYNTHETIC), SEND_FAILED with its send_failure, the messages' language named by the send, one text rule for every invoice text, a send refused 409 MERCHANT_NAME_INVALID while the merchant's name fails it, and messages held outside the send window or past 100,000 a day (SYNTHETIC)

Ajoute

  • POST /v1/invoice-batches/{id}/discard « Annuler »: discard a batch not yet sent

Codes de refus désormais nommés : INVOICE_BATCH_LIMIT_REACHED, MERCHANT_NAME_INVALID

0.60.0 · 2026-11-01

  • Invoices are declared ahead of being served: a batch of up to 50,000 invoices sent through the API in chunks of at most 1,000, through SMS, WhatsApp, both or no channel, with a reminder policy, each invoice paid through one single-use link at a time, the sandbox reminder run and the key scopes invoices:read and invoices:write; until served, an invoice route answers 403 INSUFFICIENT_SCOPE, and no webhook event is added, as a paid invoice's payment raises payment.approved

Ajoute

  • GET /v1/invoice-batches List invoice batches
  • POST /v1/invoice-batches Start an invoice batch
  • GET /v1/invoice-batches/{id} Read an invoice batch
  • GET /v1/invoice-batches/{id}/invoices List a batch's invoices
  • POST /v1/invoice-batches/{id}/invoices Add a chunk of invoices to a batch
  • POST /v1/invoice-batches/{id}/send Send a batch: create its invoices' links and first messages
  • GET /v1/invoices/{id} Read an invoice
  • POST /v1/sandbox/invoice-reminders/run Run the reminder schedule as of an instant (sandbox only)

Codes de refus désormais nommés : INVOICE_BATCH_CHANGED, INVOICE_BATCH_NOT_FOUND, INVOICE_BATCH_NOT_VALIDATED, INVOICE_BATCH_TOO_LARGE, INVOICE_NOT_FOUND, MESSAGES_NOT_CONFIGURED

0.59.24 · 2026-10-28

  • A payout key never makes a second payout: its command is remembered with what it made for ten years and refused past 720 hours, and an uploaded file's key never makes a second batch

0.59.23 · 2026-10-28

  • The Payouts description says how long payout records are kept: a command 720 hours, after which its key could make a new one (withdrawn in 0.59.24); an uploaded file until 720 hours after its upload last changed, and longer while its batch is open; a report or result file 720 hours after it was asked for; a name enquiry its budget's hour

0.59.21 · 2026-10-28

  • A payout command resent more than 720 hours after it was kept is refused 409 IDEMPOTENCY_CONFLICT and never sent again, as its first answer is no longer kept

0.59.18 · 2026-10-27

  • A name enquiry past several bounds of its budget at once is answered 429 NAME_ENQUIRY_RATE_LIMITED with Retry-After the longest of their waits, so a client that waits is not refused again by another bound

0.59.17 · 2026-10-27

  • Payout and batch events are delivered, the states an endpoint is not told of never sent, and a new endpoint is sent a payout's and a batch's outcomes by default, as a refund's

Événements de webhook désormais nommés : payout.pending_approval, payout.completed, payout.failed, payout.rejected, payout.expired, payout_batch.validated, payout_batch.completed

0.59.16 · 2026-10-27

  • Name enquiries are served within the merchant's hourly budget of 5 a destination, 60 a person or key and 300 a merchant, an exact retry counted once, so every payout route is now served

0.59.15 · 2026-10-27

  • A batch's report and result files are served: 202 with Retry-After 2 while one is being written, then the file, named after the batch's reference

0.59.14 · 2026-10-27

  • The API's description says that a payout file, uploaded in the merchant portal, is read as it streams in within 16 MiB, a longer one refused 413 REQUEST_TOO_LARGE, and the Payouts description names a third command sent under a key of its own: the batch the file makes, under a key derived from the merchant, the person and the file

0.59.13 · 2026-10-27

  • The Payouts description names the two commands sent under a key of their own rather than the caller's: a chunk of lines, known by its batch and number, and a sandbox top-up, under its own id
  • Correction to 0.59.5: moving schema_version from 1 to 2 on a payout batch, its lines, its page and its report was breaking for typed consumers, though no payout route was served yet

0.59.12 · 2026-10-27

  • The /v1 payout routes refuse a caller's own X-Futa header with 400 before anything is kept, as payment creation does, so no caller states its key's holders

0.59.11 · 2026-10-27

  • A refused chunk of payout lines may be sent again with corrected lines under its number

0.59.10 · 2026-10-27

  • A payout scope lives only by an Owner's or an Admin's delegation, so the sandbox bootstrap key and the keys Futa provisions hold none, key management alone never gives one, and every existing key no member issued loses it, one that held nothing else being revoked; a key holding a payout scope is rotated only by a caller that holds it too

0.59.8 · 2026-10-27

  • A test key tops up its sandbox payout balance through the sponsor simulator's credit notice, which carries the merchant's funding reference, and funds once under its Idempotency-Key

0.59.7 · 2026-10-27

  • The payout routes are served, but for name enquiries, batch files and the sandbox top-up: each command is kept under its Idempotency-Key before it is sent, and the holders of the key that prepares a payout are stated; an Idempotency-Key starting with payout-batch- or payout-file-, which Futa keeps for its own commands, is refused 400 INVALID_REQUEST, and so is a preparing command from a key more than 50 people have held

Codes de refus qui ne sont plus nommés : PAYOUT_VERSION_CHANGED

0.59.6 · 2026-10-27

  • Owner, Admin and Finance prepare payouts, Owner and Admin approve them, the Owner sets their thresholds, and a key an Owner or an Admin issues may hold the payout scopes

0.59.5 · 2026-10-27

  • Breaking for typed consumers: a payout batch, its lines, its page and its report move to schema_version 2; a batch never submitted that stays seven days unchanged (SYNTHETIC) ends LAPSED, a line whose route is paused waits for review as ROUTE_PAUSED, and a chunk is numbered from 1 up to the lines its batch announced

0.59.3 · 2026-10-26

  • A chunk of payout lines says what its bounds mean together, and a payout route's 400, or a name enquiry's 429, answers either the Error body or the payout refusal body

0.59.1 · 2026-10-26

  • The payout and batch webhooks are published as strict schemas, telling an endpoint the states it is sent and whether a key's holders are all known, never who they are

0.59.0 · 2026-10-26

  • Payouts are declared ahead of being served: the payout balance, name enquiries, single payouts and payout batches with every refusal catalogued, the payout key scopes, the payout and batch webhooks and the futa-payout-batch-v1 template

Ajoute

  • GET /v1/balance The payout balance, per currency
  • GET /v1/payouts Single payouts, newest first
  • POST /v1/payouts Prepare and send a single payout
  • GET /v1/payouts/{id} One payout
  • GET /v1/payout-batches Payout batches, newest first
  • POST /v1/payout-batches Start a payout batch
  • GET /v1/payout-batches/{id} One payout batch
  • GET /v1/payout-batches/{id}/lines A batch's lines, by number
  • POST /v1/payout-batches/{id}/lines Send a chunk of a batch's lines
  • POST /v1/payout-batches/{id}/lines/{line}/decision Accept, keep, remove or correct a line to review
  • GET /v1/payout-batches/{id}/validation A batch's validation: progress, counts and issue lines
  • POST /v1/payout-batches/{id}/submit Send a batch for approval
  • POST /v1/payout-batches/{id}/retry Retry a finished batch's failed lines
  • GET /v1/payout-batches/{id}/report The validation report as a futa-payout-batch-v1 file
  • GET /v1/payout-batches/{id}/result The result file as a futa-payout-batch-v1 file
  • POST /v1/name-enquiries Check a destination's holder name
  • POST /v1/sandbox/payout-top-ups Fund the sandbox payout balance

Codes de refus désormais nommés : INSUFFICIENT_PAYOUT_BALANCE, NAME_ACKNOWLEDGEMENT_REQUIRED, NAME_ENQUIRY_NOT_FOUND, NAME_ENQUIRY_RATE_LIMITED, NAME_ENQUIRY_STALE, PAYOUT_BATCH_CHANGED, PAYOUT_BATCH_INVALID, PAYOUT_BATCH_NOT_FOUND, PAYOUT_BATCH_NOT_VALIDATED, PAYOUT_BATCH_TOO_LARGE, PAYOUT_DESTINATION_UNKNOWN, PAYOUT_LINE_NOT_FOUND, PAYOUT_LINE_NOT_RETRYABLE, PAYOUT_NOT_FOUND, PAYOUT_ROUTE_UNAVAILABLE, PAYOUT_VERSION_CHANGED, PAYOUTS_HELD, RESULT_NOT_READY, TOP_UP_UNAVAILABLE

0.58.6 · 2026-10-24

  • A payment or refund read takes no Idempotency-Key: its 409 is never a key conflict, and its 200 is the payment or the refund as it stands, never a creation's answer replayed

0.58.2 · 2026-10-24

  • A read that went unanswered (503) changed nothing and can be sent again; it takes no Idempotency-Key

0.58.0 · 2026-10-24

  • The hosted sandbox, https://api.sandbox.futa-app.com, is listed first among the servers and the loopback sandbox second; nothing else changes

0.57.0 · 2026-10-22

  • A payment's or a link's return_url is an https address the checkout offers as « Retour à … », never proof of payment; any other address is refused 400 INVALID_REQUEST
  • A payment can be created with an embedding, the one https origin that may frame its checkout or an app; its Idempotency-Key binds it, and the payment echoes it
  • The webhooks are stated: the Futa-Signature header and the payment, refund and obligation collection events, with examples recorded from what is delivered
  • The sandbox takes a webhook destination on 127.0.0.1, ports 18161 to 18169, at the receiver's own path and query
  • A merchant's deliveries list an event held for it as a HELD entry naming its payment, never sent and without its body

0.56.0 · 2026-10-22

  • A POST body is read within 16 KiB unless its route states otherwise, a longer one refused 413 REQUEST_TOO_LARGE; payment creation and cancellation, the phone searches and phone verification keep their own bounds and answer 400 INVALID_REQUEST past them
  • The payment link routes answer only the closed link shape and the refusals each names: LINK_NOT_FOUND, BRANCH_NOT_FOUND and BRANCH_ARCHIVED, and 503 SWITCH_UNAVAILABLE or INVALID_LINK_RESPONSE when no valid answer comes
  • Creating a link no payer could pay, or one advertising more than the merchant's per-payment limit in its currency, is refused 409 MERCHANT_LIMIT_EXCEEDED

Codes de refus désormais nommés : BRANCH_NOT_FOUND, INVALID_LINK_RESPONSE, LINK_NOT_FOUND, REQUEST_TOO_LARGE

0.55.1 · 2026-10-20

  • Key and webhook descriptions lose a stray space at their start or end; nothing else changes

0.55.0 · 2026-10-20

  • An Accept a route cannot produce is refused 406 NOT_ACCEPTABLE and a timed-out answer 503 SERVICE_UNAVAILABLE, any other refusal of the framework keeps its own 4xx status, a client that went away is answered nothing, and only an unexpected failure is 500 INTERNAL_ERROR

Codes de refus désormais nommés : NOT_ACCEPTABLE, SERVICE_UNAVAILABLE

0.54.0 · 2026-10-20

  • Every refusal answers the Error body with a catalogued code: 405 METHOD_NOT_ALLOWED with Allow, 404 ROUTE_NOT_FOUND, 400 INVALID_REQUEST for a missing parameter, 415 UNSUPPORTED_MEDIA_TYPE and 500 INTERNAL_ERROR, logged and never detailed; on /v1 a route no scope covers is 403 INSUFFICIENT_SCOPE

Codes de refus désormais nommés : INTERNAL_ERROR, METHOD_NOT_ALLOWED, ROUTE_NOT_FOUND, UNSUPPORTED_MEDIA_TYPE

0.52.0 · 2026-10-20

  • Payment creation refuses an Idempotency-Key or a merchant_reference starting with sandbox-run-, in any case, with 400 INVALID_REQUEST: the developer console's sandbox runs reserve that prefix

0.51.0 · 2026-10-20

  • Every authenticated /v1 response carries X-Request-Id, the id the request log keeps for it

0.48.0 · 2026-10-20

  • Webhook deliveries are listed a page at a time, newest first, under a cursor sealed to the list and the merchant (400 INVALID_CURSOR otherwise), each with its state and, for a payment event, the payment's reference; a delivery's attempts say when each was recorded and the HTTP status answered, 0 for no answer

Codes de refus désormais nommés : INVALID_CURSOR

0.47.0 · 2026-10-20

  • A key never grants keys:manage: asking for it when issuing a key, or rotating a key that holds it, is refused 403 SCOPE_ESCALATION

Codes de refus désormais nommés : SCOPE_ESCALATION

0.44.0 · 2026-10-18

  • Payment creation may be refused 409 MERCHANT_LIMIT_EXCEEDED, above the merchant's per-payment limit or, for a direct payment, its limit for the day or the month in Kinshasa time, or 409 PARTICIPANT_LIMIT_EXCEEDED, above the participant's maximum per transaction
  • A refund may be refused 409 MERCHANT_LIMIT_EXCEEDED past the day's refunds limit of the merchant's risk profile
  • The success rate counts only the payments the payer submitted that ended, so an intent that expired unpaid is not a failure

Codes de refus désormais nommés : MERCHANT_LIMIT_EXCEEDED, PARTICIPANT_LIMIT_EXCEEDED

0.43.0 · 2026-10-18

  • A settlement's policy may be synthetic-cycle-funded-v3

0.41.0 · 2026-10-17

  • The payment link list counts the links still payable that expire before the end of tomorrow, Kinshasa time (counts.expiring)

0.39.0 · 2026-10-17

  • A settlement's period starts after the previous settlement with an earlier cutoff, and period_start is null when no collection precedes the cutoff; a verified destination's account version may reach 201

0.38.0 · 2026-10-17

  • Breaking for payment link readers: a link loses reference and payment_state, its code naming it instead, DECLINED is no longer one of its statuses, its amount is null for an open amount, and creating one takes its own body, PaymentLinkCreate, in place of HostedPayment
  • A payment link is its own record, apart from the payments made through it: a fixed amount or an open amount within optional bounds, single or multiple use, lasting 1 to 720 hours, with its status, what it has collected and its latest attempts; the link list counts the links and the unpaid ones
  • Sharing a link is refused 409 LINK_NOT_SHAREABLE, and cancelling it 409 LINK_NOT_CANCELLABLE, when its state does not allow it; cancelling a payment says how an attempt made through a link answers
  • A settlement carries its RG reference, its period with its collections by method and completed refunds, its lines and its follow-up; the list names each currency's upcoming settlement with its net, never a date; a statement above 10,000 lines is refused 409 STATEMENT_TOO_LARGE

Codes de refus désormais nommés : LINK_NOT_CANCELLABLE, LINK_NOT_SHAREABLE, STATEMENT_TOO_LARGE

0.37.0 · 2026-10-13

  • A payment's detail and its state timeline are read (GET /v1/payments/{id}/detail and GET /v1/payments/{id}/detail/events)
  • Payments are searched by the payer's exact phone number, sent in the body and never in the URL, and the matches exported (POST /v1/payments/search/phone and its export)
  • A refund above the merchant's threshold waits PENDING_APPROVAL until a person other than the requester approves it in the portal, and may end REJECTED or EXPIRED; an endpoint can choose refund.pending_approval, refund.rejected and refund.expired
  • A refund's refusals are named: REFUND_AMOUNT_EXCEEDED, PAYMENT_NOT_REFUNDABLE, REFUND_METHOD_UNSUPPORTED and REFUND_WINDOW_EXPIRED, and a refund amount that is not a whole unit of its currency, whole francs in CDF, is refused 400 INVALID_REQUEST
  • The payment summary counts declined, expired and in-progress payments, a listed payment carries the payer's masked number, and bank payments are a method filter
  • Creating, sharing and cancelling a payment link need payments:write

Ajoute

  • GET /v1/payments/{id}/detail Read the private synthetic payment evidence detail
  • GET /v1/payments/{id}/detail/events Read the private synthetic payment state timeline
  • POST /v1/payments/search/phone Search merchant payments by exact private phone
  • POST /v1/payments/search/phone/export Download matching phone-filtered payments

Événements de webhook désormais nommés : refund.pending_approval, refund.expired, refund.rejected

Codes de refus désormais nommés : PAYMENT_NOT_REFUNDABLE, REFUND_AMOUNT_EXCEEDED, REFUND_METHOD_UNSUPPORTED, REFUND_WINDOW_EXPIRED

0.36.0 · 2026-10-11

  • A payment is created direct, with the sandbox simulator and one of its synthetic numbers, or hosted as before; its body is bounded and refused with unknown or duplicate fields, and a CDF amount is whole francs, a multiple of 100
  • An unsubmitted payment is cancelled (POST /v1/payments/{id}/cancel)
  • A collected payment's PDF receipt is downloaded (GET /v1/payments/{id}/receipt.pdf)

Ajoute

  • GET /v1/payments/{id}/receipt.pdf Download a private PDF receipt for this exact collected payment
  • POST /v1/payments/{id}/cancel Cancel an unsubmitted merchant payment

Codes de refus désormais nommés : BRANCH_ARCHIVED, DIRECT_PAYMENT_NOT_ADMITTED, INSUFFICIENT_SCOPE, INTENT_EXPIRED, INVALID_API_KEY, INVALID_CANCELLATION_RESPONSE, INVALID_CREATION_RESPONSE, INVALID_REQUEST, METHOD_UNAVAILABLE, PARTICIPANT_CAP_EXCEEDED, PAYMENT_NOT_CANCELLABLE, PAYMENT_NOT_FOUND, RATE_LIMITED, SWITCH_UNAVAILABLE

0.35.0 · 2026-10-11

  • An endpoint can choose obligation.collected, sent once an obligation is collected

Événements de webhook désormais nommés : obligation.collected

0.34.0 · 2026-10-11

  • A payment's obligation is read (GET /v1/payments/{id}/obligation): the collection it belongs to and its attempts in order

Ajoute

  • GET /v1/payments/{id}/obligation Read the collection and ordered attempts of a payment obligation

0.33.0 · 2026-10-10

  • GET /v1/methods leaves out a suspended route, and answers an error rather than a method when the switch is unavailable

0.31.0 · 2026-10-10

  • A key issued or rotated may hold settlements:read: IssuedKey lists it among its permissions, as the key request and the key's metadata already did

0.26.0 · 2026-10-10

  • A settlement under the synthetic-verified-destination-v2 policy carries the merchant's frozen, masked verified destination (verified_destination); an earlier statement gives null

0.15.0 · 2026-10-09

  • A payment can be created for one of the merchant's active branches (branch_id), which it keeps for good; payments and payment links carry the branch's id, code and name, and the payment list, summary and export filter by branch

0.13.0 · 2026-10-09

  • Settlements are listed and read, and a settlement's statement downloads as PDF or CSV (GET /v1/settlements/{id}/statement), under the new settlements:read scope; a legacy settlement without a frozen breakdown has no statement, refused 409 STATEMENT_UNAVAILABLE

Ajoute

  • GET /v1/settlements List merchant settlements
  • GET /v1/settlements/{id} Get merchant settlement
  • GET /v1/settlements/{id}/statement Download merchant settlement

Codes de refus désormais nommés : STATEMENT_UNAVAILABLE

0.12.0 · 2026-10-09

  • Payment links are created, listed, read, shared and cancelled under /v1/payment-links, a link's share URL revealed only by its own route

Ajoute

  • GET /v1/payment-links listPaymentLinks
  • POST /v1/payment-links createPaymentLink
  • GET /v1/payment-links/{id} getPaymentLink
  • GET /v1/payment-links/{id}/share sharePaymentLink
  • POST /v1/payment-links/{id}/cancel cancelPaymentLink

0.11.0 · 2026-10-09

  • Filtered payments download as CSV or XLSX (GET /v1/payments/export), at most 5,000 rows, a larger export refused 413 EXPORT_TOO_LARGE so the filters can be narrowed

Ajoute

  • GET /v1/payments/export Download filtered merchant payments as CSV or XLSX

Codes de refus désormais nommés : EXPORT_TOO_LARGE

0.10.0 · 2026-10-09

  • Payments are filtered by reference, amount, currency, state, method and period, each lists its method, and GET /v1/payments/summary gives a per-currency summary of the payments for a period and for today, in Kinshasa or Lubumbashi time

Ajoute

  • GET /v1/payments/summary Read per-currency merchant payment dashboard

0.9.0 · 2026-10-09

  • A webhook endpoint chooses the events it is sent and changes its destination under a version (POST /v1/webhooks/endpoint/configuration); the event types are named, and a delivery says its event type, whether it was selected and the configuration version it went under

Ajoute

  • POST /v1/webhooks/endpoint/configuration Update the allowlisted destination and new-event subscriptions

Événements de webhook désormais nommés : payment.created, payment.pending_approval, payment.uncertain, payment.approved, payment.declined, payment.expired, refund.queued, refund.processing, refund.uncertain, refund.completed, refund.failed

Codes de refus désormais nommés : EVENT_NOT_SUBSCRIBED, IDEMPOTENCY_CONFLICT, WEBHOOK_CHANGED

0.8.0 · 2026-10-09

  • A key's metadata names who issued it, issued_subject, and issued_membership_version, both nullable

0.7.0 · 2026-10-09

  • The API's description says that a merchant's team members use verified multi-factor identities, each with the least privileges their role needs, and that there is no production enrolment or email delivery

0.6.0 · 2026-10-09

  • Payments are listed, the 25 newest at a time under a cursor, and a payment says how much its queued, processing or uncertain refunds reserve

Ajoute

  • GET /v1/payments List merchant payments

0.4.0 · 2026-10-09

  • Refunds: a full or partial refund of a payment within 180 days, to the original account only, read by its id or listed under its payment; a payment carries its refund status and refunded amount, and a key may hold refunds:read and refunds:write

Ajoute

  • GET /v1/payments/{id}/refunds List refunds linked to a merchant-owned payment
  • POST /v1/payments/{id}/refunds Request a full or partial refund within 180 days
  • GET /v1/refunds/{id} Read the current merchant-owned refund status

0.3.0 · 2026-10-09

  • Merchant keys are listed, issued, rotated and revoked, each with its own permissions; a merchant registers one webhook endpoint, rotates its signing secret, lists its deliveries and their attempts, and replays an event without changing its identity

Ajoute

  • GET /v1/keys List key metadata without secrets
  • POST /v1/keys Create a restricted test key
  • POST /v1/keys/{id}/rotate Atomically replace and revoke a test key
  • POST /v1/keys/{id}/revoke Revoke a merchant-owned key
  • GET /v1/webhooks/endpoint Read merchant webhook configuration
  • POST /v1/webhooks/endpoint Register the merchant webhook endpoint
  • POST /v1/webhooks/endpoint/rotate Rotate merchant webhook signing secret
  • GET /v1/webhooks/deliveries List latest 100 merchant deliveries
  • GET /v1/webhooks/deliveries/{id}/attempts Read attempts for a merchant-owned event
  • POST /v1/webhooks/deliveries/{id}/replay Replay an event without changing its identity

0.2.0 · 2026-10-09

  • The first contract: a sandbox payment is created under an Idempotency-Key and read by its id, and the payment methods are listed

Ajoute

  • POST /v1/payments Create an idempotent sandbox payment
  • GET /v1/payments/{id} Read authoritative payment status
  • GET /v1/methods List sandbox payment methods