Every provider parameter, every allowed value, every payment scenario — mapped to a test case. Integrations QC is the ledger that proves, line by line, which part of each integration we've actually verified. Scaling ~500 tests per provider to 2,000+ — mostly E2E, all traceable.
“We don't assume the provider does what the spec says. We prove it — parameter by parameter, value by value.”
Dashboard on the left: every PSP we integrate with, coverage at a glance. Drill on the right: requirement-by-requirement status, with the test case that proves each covered line.
Four practices that hold the matrix up. Each one is boring on its own — together they're the difference between "it passed sandbox" and "we've audited every path in production."
For each field we send a provider: business purpose, allowed values, expected behavior, financial and functional impact. The matrix guarantees every relevant value has at least one test case behind it.
Standardized per test case: auto or manual · sandbox or production · untestable (with justification) · not applicable (explicit, not missing). Evidence attached. No ambiguous rows.
For every parameter we ask four questions. Four tests, same matrix. A row stays red until all four answers are green — or the row is explicitly marked untestable with a reason.
Each integration grows from ~500 tests today to 2,000+ — mostly E2E against sandbox + production. Not a vanity metric: every new test closes a specific row on the matrix that was open before.
Provider specs are long, incidents are expensive, and “it worked in sandbox” has cost us too many edges. Integrations QC treats every parameter as an assertion we own — and every open row on the matrix as a release blocker until the test exists or the row is marked explicitly untestable.
A provider integration ships with a coverage report, not a README. If a row is missing, the integration is not ready — regardless of what the sandbox says.
Some cases genuinely can't be reproduced (a provider-side fraud flag, a chargeback callback). They get marked with a reason and stay on the matrix — never silently dropped.
Parameters come from the provider OpenAPI. Test-to-requirement links live in the spec files as @tags (@REQ-PC-001, @OP-012). The matrix is a report, not a spreadsheet anyone curates by hand.
Each covered row carries the order ID, the environment (sandbox / production), the run timestamp. An auditor can trace any line to a real transaction.
Isn't this just integration testing?
Integration tests prove the suite passes. The matrix proves WHAT the suite covers — requirement by requirement. It's the audit trail on top: we can say “every apple-pay × 3DS combination is green” with numbers, not hope.
2,000+ tests per integration — isn't that overkill?
A PSP routes millions per day. A missed edge is priced in GMV leak, not engineer-days. Exhaustive coverage is cheaper than one production incident on a retry path nobody tested — the one Monitors catches 42 minutes after it starts leaking.
Who maintains the traceability matrix?
Nobody, by hand. Parameters are generated from the provider OpenAPI. Test-to-requirement links are @tags asserted in the spec files themselves. The matrix is rebuilt on every merge — a report, not a wiki.