Integration test plan
Use this checklist to prove that your integration handles the enabled card features and the transaction events it can receive. Each row links to the handling rule, identifies the messages to use and states the result to check.
Download the checklist and test steps (JSON)
Choose the applicable tests
Use one checklist for the program. Run every row marked Every integration, then add the rows whose enabled features apply. A media-buying program still needs purchase, clearing, reversal, refund, retry and matching checks. ATM or estimated-amount completion scenarios can be marked not applicable only when those features are excluded by program configuration. Completion advice can apply to fuel, taxi fares or other merchants that initially authorize an estimate.
Record passed, failed or not applicable for each test, with a reason for every exclusion. A feature is not excluded simply because it is outside the expected customer journey.
Before testing, confirm decisioning responsibility, card/account mapping, enabled features, reference-fallback scope and time window, amount-update rules, hold expiry, permitted excesses and funding policy. These settings determine the expected behavior where a row refers to a configured rule.
Run the message tests
Download the complete masked messages and replay them through your local integration test harness. Keep the recorded bodies unchanged. Tests labelled simulated variation deliberately exercise duplicates, delivery order, conflicts or additional account entries; they are not extra recorded FINCI messages.
For every applicable test:
- Record each message's own
id, lifecycle phase,response_codeand original references. - Record the held amount and posted movement after each message, separately for each account and currency.
- Compare those results with the expected result below.
- Retain sanitized evidence and the test status in the downloaded checklist.
The fictional IDs in the downloads are local fixtures. Use provisioned sandbox cards and test data for API and network testing with FINCI.
Implementation checklist
| Test and handling rule | Run when | Messages | Expected result |
|---|---|---|---|
Every integration | Provisioned sandbox | The account maps to its person or company; token_id maps to the individual cardholder and configured account. No invented account_id or corporate_id is added to the create-card body. | |
Every integration | Provisioned sandbox | deactivated is temporary. closed, compromized, damaged, lost and stolen cannot return to active. plastic_not_delivered orders the physical card with delivery pending; status is unchanged. Existing holds and postings still follow their transaction rules. | |
Every integration | Every ID digit and string reference survives unchanged. Decimal money is exact. Every accounts_local entry is processed in its own currency. | ||
Every integration | Test harness; simulated variation | The configured receiver accepts valid test traffic and rejects traffic that fails verification before a financial effect. Secrets and verification codes do not appear in logs. | |
Every integration | Hold EUR 10.65, then keep EUR 10.65 with posted movement EUR 0.00. Presentment posts EUR -10.65 once and leaves hold EUR 0.00. | ||
Every integration | Initial decline is HTTP 403 with status error, not HTTP 200. Preserve confirmation response_code "Insufficient funds" and acknowledge its receipt. Release any provisional hold. Posted movement remains EUR 0.00. | ||
Integrator-managed decisions | FINCI sandbox session | Record the received outcome under the same authorization id; release any provisional hold if declined. A local timer alone does not fabricate a network outcome. | |
Every integration; concurrent decisions where integrator-managed | Replay the saved initial response. Each hold change, reversal and posting occurs once. Concurrent approvals cannot reserve the same available funds twice. | ||
Every integration | The confirmation is processed as a later phase rather than discarded as a duplicate. Negative confirmation amounts do not create postings; advice is not the phase classifier. | ||
Every integration | Posted movement is EUR -6.00; the full EUR 6.50 hold is released. Remaining hold is EUR 0.00 and EUR 0.50 becomes available again. No separate expiry or reversal is needed. | ||
Every integration | The first presentment releases the entire EUR 0.01 hold. Post both presentments once: total EUR -5.80; hold remains EUR 0.00. Matching authorization_id and amount do not make the second record a duplicate. This fixture does not define a permitted excess limit. | ||
Every integration | Store the reversal under its own id. Release up to the eligible EUR 2.55 hold, including the fee already in that total. No refund is posted. | ||
Every integration | The supported unique rrn match links the reversal. Hold becomes EUR 7.54, then EUR 0.00; clearing posts EUR -7.54 once. Reversal id remains separate from the earlier authorization id. | ||
Every integration | original_authorization_id links the exact earlier id. original_authorization_nrn equals the earlier nrn. E03 is an approved additional authorization with advice false, not an advice message. | ||
Every integration | Download E05; simulated variation | One qualifying match resolves the link. A missing explicit target stays pending without RRN fallback; multiple candidates or out-of-scope records remain unresolved and do not release an unrelated hold. This is a simulated variation, not another recorded FINCI message. | |
Every integration | Download E03; simulated variation | Missing explicit targets remain pending; no weaker fallback replaces them. Conflicts stay unresolved. Later resolution does not repeat the financial effect. | |
Every integration | Download E03; simulated variation | Post once. After linkage resolves, close the whole matched reservation without reposting or creating a new hold for the already-cleared authorization. | |
Every integration | Download E01; simulated variation | Retain the changed-payload conflict. There is no second posting merely because the account array changed. | |
Every integration | Download E07; simulated variation | Apply configured expiry once. Post a late distinct clearing once without reopening an expired hold. A reversal after expiry or clearing releases nothing and does not refund a posted debit. | |
Every integration | Return approval does not post a refund. Presentment posts EUR +177.17 once; authorization_id refers to the return authorization, not automatically to the earlier purchase. | ||
Every integration | Post EUR -1.84 once and retain the clearing without inventing an authorization link. An empty reference alone does not prove an offline transaction. | ||
Programs with multiple local account allocations | Test harness; simulated variation | Post only the supplied EUR movement. Close the whole matched authorization reservation, including its EUR and GBP allocations; keep an unrelated authorization hold unchanged. Never combine different currencies. Authorization identity does not depend on identical account arrays. | |
Programs that allow cross-currency purchases | Keep USD 49.99 for original purchase display. Hold EUR 45.00, then post EUR -45.00 once. Presentment has Transaction EUR +44.78, Markup EUR -0.22 and account_local_rate 1; its Transaction currency matches account_currency EUR. The EUR 0.22 markup is included; do not reserve EUR 45.22 or post another fee. | ||
Programs that allow cash withdrawals | Hold EUR 223.18, then post EUR -223.18 once. Fee is the EUR 6.88 ATM fee; Markup is EUR 1.08. They combine into local fee_amount EUR 7.96, already included in account_amount. Do not charge any component again. | ||
Programs that support estimated-amount completion advice, including fuel or taxi fares | Keep both authorization records and their link. advice is true on the later message. Hold becomes EUR 29.12 and EUR 95.88 is released once. Posted movement stays EUR 0.00: this example contains no presentment. | ||
Programs that support this additional-authorization flow | Hold becomes EUR 29.34 and clearing posts EUR -29.34 once. This additional authorization has advice false; the completion advice in T25 has advice true. A declined additional authorization does not cancel the earlier approval. | ||
Every integration | The uncovered amount is accounted for under the agreed funding rules. Reconciliation retains distinct presentment IDs. A higher clearing amount alone does not establish a chargeback right. | ||
Integrator-managed decisions | Download E01, Download E08; simulated variation | The transport status and JSON decision agree. Approval is 200/success; decline is 403/error. Retries replay both. A received decline confirmation is acknowledged with 200/success and creates no posting. |
Sign check: request amounts and confirmation amounts can have different signs. A negative confirmation is not a posting. A positive reversal releases an eligible hold. Post the signed local amount only from a presentment; do not negate it again using sign.
Complete validation with FINCI
- Every applicable local test has passed and each exclusion has an agreed reason.
- Provisioned customer, account and card setup has been tested in sandbox.
- Decision, decline and timeout behavior has been confirmed in the FINCI-supported session where integrator-managed decisioning applies.
- Delivery responses, retry handling and enabled event types have been confirmed with FINCI.
- The completed checklist and sanitized traces are ready for the onboarding review.
Continue with Validation and go-live for sandbox acceptance and controlled production confirmation testing. A local fixture replay does not replace that process.