Testing
Integration checklist
Complete each check in the sandbox. Each row says why it matters.
Credentials#
| Check | Why |
|---|---|
| Your server, and only your server, sends API requests. | An API key in a browser or an app is exposed to everyone. |
| Each key holds only the scopes that its caller needs. | A leaked key can do less. |
| Keys and webhook secrets are in a secret store, not in source code. | Committed secrets leak through history and copies. |
Requests#
| Check | Why |
|---|---|
Every create and command request sends a unique Idempotency-Key, and a retry reuses it. |
A retry must not create a second resource. |
Your client retries 5xx and 429 with backoff, and does not retry other 4xx. |
Only some errors can succeed on a retry. See Retries. |
Your code reads the error code from errorCode or error.code. |
The body shape depends on the endpoint. See Errors. |
Your logs keep the X-Request-Id of each response. |
It identifies a request when you need help. |
| Your code ignores fields that it does not know. | Merxian can add fields to responses and events. |
| Amounts are handled as integers in minor units. | 14280 in EUR is €142.80, not €14,280. |
Checkout and payments#
| Check | Why |
|---|---|
You fulfil on payment.succeeded or transaction.completed, not on the return to successUrl. |
Anyone can open the success URL. |
You store the session url from the create response. |
Later reads do not include the access token. |
| Failed, canceled, and expired payments leave your record in a clear state. | The buyer can try again, or the sale must close. |
| Your code treats an unknown payment state as not final. | New states can be added. |
Webhooks#
| Check | Why |
|---|---|
Your endpoint verifies Merxian-Signature before it trusts a request. |
Anyone can send a request to your endpoint. See Verify signatures. |
Your endpoint returns 2xx quickly and does slow work later. |
A slow response counts as a failure and causes retries. |
Your endpoint processes each event id once. |
Merxian can deliver an event more than once. |
| Your code does not rely on the order of events. | Merxian does not guarantee an order. |
| You subscribed to every event that your code handles. | An endpoint receives only the events that it subscribes to. |
Refunds and records#
| Check | Why |
|---|---|
You act on refund.succeeded and refund.failed, not on the 202 response. |
A refund result arrives later. |
| You read the transaction before you repeat an unclear refund request. | A second refund can return money twice. See Refund a payment. |
| You compare your records with a periodic list of transactions. | Events alone can miss a change. See Reconcile with your records. |