Skip to main content

Multi-Processor Certification Evidence

Use this runbook for Sierra, Fiserv Rapid Connect, Elavon Fusebox, and Fiserv CardPointe certification evidence handling.

Scope

  • Sierra, Rapid Connect, Fusebox: still vendor-gated — prep/scaffold evidence only until sandbox/MIDs/certification material arrives (see Wave Boundaries below).
  • Fiserv CardPointe: live in the CardPointe UAT sandbox. Verify CardPointe transactions through the CardPointe reporting tool at https://cardpointe-uat.cardconnect.com (login is vendor-issued per rep; do not store credentials in this repo). Sandbox test MIDs: 800000070034 (PeakPOS IC Plus) and 800000070035 (PeakPOS Surcharge-enrolled) — use the surcharge MID only when validating surcharge pass-through evidence, and the IC-Plus MID otherwise.

Before Running

  • Confirm the worktree branch and deployed Cloud Run revision.
  • Confirm the active image is AMD64 and matches the intended commit.
  • Confirm the provider route is explicitly assigned to the test location/use case.
  • Confirm vendor credentials and test scripts are approved for the target environment.
  • For CardPointe: confirm which sandbox MID (IC-Plus vs. surcharge-enrolled) the credential profile under test points at, since surcharge behavior differs between them.

Evidence Handling

  • Write local artifacts under tools/certification/cert-runs/<date-provider-purpose>/.
  • Store raw request/response logs only in the approved evidence bucket or vendor portal.
  • Keep redacted-summary.md free of PAN, track data, PIN data, cryptograms, raw network tokens, and decrypted credential payloads.
  • Include manifest.json with commit, deployed revision, provider/platform, environment, script name, and raw evidence URI.
  • Run the relevant validator before submitting evidence for review.

Submission Notes

  • A green local fake-contract run is not certification.
  • A vendor approval must identify provider, platform, environment, test script/version, merchant/terminal scope, and approved operation set.
  • If a step fails because credentials, boarding, mTLS, or scripts are missing, record it as a readiness blocker, not an adapter approval failure.
  • For CardPointe UAT verification specifically, use the CardPointe reporting tool transaction detail (respstat/respcode/retref) as the source-of-truth cross-check against gateway-side processor_attempts/transactions rows — do not rely on gateway logs alone to claim a UAT-verified result.

Wave Boundaries

  • Wave 6 may improve evidence plumbing and fake-host coverage for the still-vendor-gated providers (Sierra, Rapid Connect, Fusebox).
  • Wave A (CardPointe) is live end-to-end; its evidence trail runs through CardPointe UAT plus the reporting tool above rather than through the vendor-gated Wave 6 process.
  • Wave 7 smart routing has an implemented MVP (see websites/support-docs/docs/integrations/cardpointe.md and the #883 plan) limited to the TSYS:TRANSIT/FISERV:CARDPOINTE certified-eligible pair; broader smart-routing evidence requirements are still design work.
  • Wave F controls 3DS2, wallets, network-token provisioning, cryptograms, and device/TTP foundations.