Payment Integration Verification Matrix
Record each country, merchant, provider, terminal, controller, interface and network combination separately. An expected result is a test input, not an established compatibility result.
Use one test-plan record for each country, payment provider, terminal and controller combination. Define the configuration and acceptance criteria before payment integration checks. Applicable scope: each record proves only the observed cases for the named country, account, hardware and software combination.
Swipe horizontally to see every column.
| Verification area | Expected result | Actual observation | Outcome | Evidence reference | Reviewer / date | Open action / retest |
|---|---|---|---|---|---|---|
| Define the exact integration combination | Project input | Project input | Not assessed | Project input | Project input | Project input |
| Confirm account and settlement responsibilities | Project input | Project input | Not assessed | Project input | Project input | Project input |
| Trace an approved payment through machine completion | Project input | Project input | Not assessed | Project input | Project input | Project input |
| Check declined, cancelled and interrupted transactions | Project input | Project input | Not assessed | Project input | Project input | Project input |
| Verify reversal, refund and reconciliation | Project input | Project input | Not assessed | Project input | Project input | Project input |
| Review network recovery and service access | Project input | Project input | Not assessed | Project input | Project input | Project input |
| Close the record with evidence and limits | Project input | Project input | Not assessed | Project input | Project input | Project input |
Define the exact integration combination
Create a separate record for each proposed country, currency, acquiring provider, merchant account arrangement, terminal model, machine controller and software version. Include the interface or protocol version and the intended network connection. Agree the test scope for each integration combination.
Payment Options & Country Compatibility Review — Input to this matrix: the country, merchant and provider, plus a completed cycle and a charge with no completed delivery.
Software Access, Data & Service Ownership — Input to the controller software version and interface fields: the account holder, the documented interface, and a software or interface change recorded as its own case.
Trace payment and equipment evidence separately
Confirm account and settlement responsibilities
Ask the proposed payment provider to confirm the account prerequisites and the operator responsible for registration, settlement, fees and ongoing service. Record the dated provider response and its scope.
Trace an approved payment through machine completion
Agree a test procedure for the exact configuration with our engineering team and the payment provider. Record the amount requested, payment result, machine action and completion signal using non-sensitive test references. A payment success screen alone is insufficient evidence of a completed machine transaction.
Check declined, cancelled and interrupted transactions
Document the expected customer and operator behaviour when a payment is declined, cancelled or interrupted. Use an agreed test environment and supported procedure; do not add live fault tests that the procedure does not include.
Failed Payment, Failed Service & Refund Workflow — Next step when authorisation succeeds and the machine does not finish: record the machine event and the payment status, then who investigates the refund.
Verify reversal, refund and reconciliation
Record who can initiate a reversal or refund, the supported procedure and the evidence linking the payment reference to the machine event. Compare the machine record with the provider record for the agreed test cases.
Review network recovery and service access
Agree how to observe loss and restoration of the required connection without bypassing protection or exposing live customer information. Record whether transactions are blocked, queued or require operator action only after observing the supported behaviour.
Close the record with evidence and limits
For each row record the expected result, actual observation, dated evidence reference, reviewer and outcome. Use not tested, pass, fail or not applicable; explain any not-applicable decision. Reassess relevant cases after an account, provider, firmware or interface change. Use this worksheet to agree payment integration checks for the selected country, provider and machine configuration.
Frequently asked questions
Does a merchant or firmware change need a new test?
Reassess the relevant cases after an account, provider, firmware or interface change. A result for another country, account, firmware version or machine is its own record. A pass applies only to the combination already recorded.
Which row records an authorised payment when the machine does not complete?
Record it on Trace an approved payment through machine completion. Keep the payment result and the machine action or completion signal as separate observations. A payment success screen is not a completed machine transaction, and the expected-result field stays the test input.
How should not tested and not applicable be recorded?
Use not tested when the case was not run, and not applicable when the decision explains why the case is outside the agreed combination. Keep failed and untested cases beside successful observations. Neither label is a pass.
Can I get a refund from a vending machine?
Verify reversal or refund handling for the exact provider, merchant, terminal, controller and software combination. Record expected behaviour, actual observation, the non-sensitive reference and authorised owner; neither payment authorisation nor an expected-result field proves automatic refund support.