Test Cases and Reference Code
The integration kit holds code and test cases as files, under the MIT licence. index.json lists every file. Download what you need. Don't import it blind: port it to your own language and framework, and keep the behaviour identical.
Test cases: port every case
| File | Partner | Direct seller | Covers |
|---|---|---|---|
test-vectors/money.json |
✓ | ✓ | Amount conversion and limits |
test-vectors/sale-query-verification.json |
✓ | ✓ | Confirming a sale from query rows |
test-vectors/subscription-verification.json |
✓ | ✓ | Confirming a subscription from query rows |
test-vectors/partner-signatures.json |
✓ | Signature digests and outcomes | |
test-vectors/partner-callbacks.json |
✓ | What a partner does with each callback | |
test-vectors/seller-callbacks.json |
✓ | What a seller does with each callback |
Each file states its case_count. Fail your test run if a file has fewer cases than that.
Reference code
| File | Use for |
|---|---|
reference/payme-client.ts, reference/payme-error.ts |
Transport, the success test, error handling, redaction |
reference/money.ts |
Amounts |
reference/payme-types.ts |
Request, response and callback shapes |
reference/callback-fields.ts |
Classifying and reading a callback body |
reference/sale-query-verification.ts, reference/subscription-verification.ts |
Confirming by query |
reference/partner-signature.ts, reference/partner-callbacks.ts |
Partners: signature checks and callback routing |
reference/seller-callbacks.ts |
Direct sellers: callback routing |
browser/hosted-page.html, browser/hosted-fields.js |
The browser side |
The reference covers the pieces with one right answer. Request builders, order matching, locks and state changes are yours to write, in your project's style.
Tests for your own code
Passing the published test cases proves the pieces you ported, not the service around them. Bugs in your connecting code still need these service tests and an independent review by someone who didn't write the code.
Test that:
- a forged callback gets a status below 400 and changes nothing;
- a confirmed sale is fulfilled once when its callback arrives twice;
- a callback can't move a sale backwards;
- a partial refund sequence ends with the right total and the status
partial-refund; - amounts below the minimum or with decimals never reach PayMe;
- credentials and tokens never appear in logs, responses or a browser bundle;
- money-moving endpoints refuse unauthenticated callers;
- a charge that timed out is checked, not retried;
- each row of Reading a failure gets its outcome: HTTP 500 with code
305is refused, code20002at HTTP 200 is unknown, HTTP 429 means re-read first, and a non-JSON 500 is unknown; - a
failedsale can still become paid, and is fulfilled once; - every row of Implementation Traps that applies to you.