Payments Migration: Acceptance Criteria Before You Fund the Build
Scope a payments migration around reconciliation, retries, historical transactions and cutover evidence. A buyer's acceptance checklist before funding implementation.
Finance and engineering should agree on the evidence required to move payment traffic before they approve the migration build. Otherwise they can reach the cutover meeting with different definitions of finished.
Engineering may have completed the integration. Finance may still be unable to explain an unsettled balance. Operations may have no way to resolve a payment that completed at the provider after the application timed out.
All of that can happen with a functioning API connection. The contract needs to cover the behavior of the payment system around it.
Put the money flows in the scope
Start with the flows that exist today, including the ones handled manually. For each flow, identify the system that initiates it, the system recording its status, the settlement evidence and the owner of exceptions.
Include refunds, disputes, returns and adjustments where the product supports them. A migration plan built only around new successful payments leaves the old system's obligations behind in an undocumented operating process.
The provider change may also alter identifiers, reporting formats and status meanings. Write the mapping down. A status named “complete” is not enough to establish what has happened to the money or which later events can affect it.
For the underlying ledger decisions, use the existing guide to reconciliation and ledger architecture. The migration decision adds another concern: how old and new records can be compared while both systems remain relevant.
Buy evidence against these acceptance criteria
The following table is a scoping framework. Adapt it to the payment products and providers in use, then give each criterion a named internal approver.
| Area | Evidence before cutover | Scope question for the supplier |
|---|---|---|
| Transaction identity | A mapping between business operation, provider references and ledger entries | What prevents a retry from creating a second economic operation? |
| Reconciliation | Reproducible comparison of the relevant operational, ledger and settlement records, with an exceptions queue | Who investigates a mismatch and what information do they receive? |
| Delayed and repeated events | Test results for repeated notifications and events arriving after other state changes | Can the same event be processed again without repeating its financial effect? |
| Historical obligations | A documented route for refunds, disputes and other later activity on old transactions | Which functions must remain with the old provider, and for how long? |
| Cutover | A staged traffic plan with stop conditions and an accountable decision maker | What evidence allows the next group of traffic to move? |
| Recovery | An exercised procedure for stopping new traffic and resolving in-flight work | Which effects can be reversed, and which require a compensating operation? |
| Operations | A runbook tested by the people who will use it | Can the internal team investigate an exception without the migration engineer? |
Do not accept “parallel run” without a description of what runs in parallel. Comparing calculations or shadowing data is different from submitting the same real payment through both providers. The plan must prevent duplicate financial effects while producing evidence that can be compared.
Use provider documentation to construct failure cases
Take Stripe as a concrete example, rather than assuming every provider has the same behavior. Its webhook documentation says event ordering is not guaranteed and duplicate deliveries can occur. Those are conditions an integration must handle, not unusual accidents to exclude from testing. Source: Stripe webhook documentation, checked September 25, 2026.
Stripe also documents the behavior and retention of idempotency keys. Review those rules against your retry policy, including what happens after the provider no longer retains a key. Provider request deduplication and your business operation's identity have different lifetimes. Source: Stripe idempotent requests, checked September 25, 2026.
Apply the same reading to the actual providers in the migration. Capture their documented guarantees, the assumptions your application makes and the tests that would expose a mismatch. Do not infer another provider's guarantees from this example.
Separate delivery ownership from executive authority
An existing CTO can commission a migration workstream and retain the wider technology decisions. The external team's remit can include implementation, test evidence and cutover preparation, while the business retains authority to move traffic and accept residual risk.
That is a senior engineering contract. It does not require relabeling the delivery lead as a fractional CTO.
If nobody can resolve the priority conflict between finance, operations and engineering, the problem includes leadership. A fractional or interim CTO needs a written decision remit and access to the people who own those functions. Giving a consultant responsibility without that authority creates another escalation step.
The proposal should identify which situation applies. Price the agreed capacity, include preparation and operational handover, and make scope changes visible before extra work begins. A low hourly quote attached to an incomplete scope is a poor basis for comparing suppliers.
Make the exit test part of the first agreement
The engagement should end with more than traffic reaching the new provider. The internal team needs to know where unresolved transactions live, which old contracts or integrations remain necessary, and who owns each remaining task.
Require a handover exercise using a representative exception. Ask the internal operator to locate the evidence, explain the transaction state and follow the documented recovery process. Any step that depends on the supplier's memory is unfinished handover work.
AZdev provides payment systems modernization through scoped engineering engagements, with separate fractional and interim CTO support when the wider technical leadership is also missing. Start with the acceptance criteria and the unresolved ownership questions when scoping the engagement.