In this essay
A merchant chooses a payment gateway because it supports the required cards and currencies. After launch, a refund stalls. The gateway says the acquiring team must investigate; the acquirer asks for evidence held by the merchant's integration provider.
The feature comparison did not answer who would resolve this case. Payment gateway evaluation needs a responsibility map alongside the checkout demonstration.
Start with the contracted route
Write down the actual route proposed for the merchant, including the entity providing each service. One company may perform several roles; another arrangement may divide them across separate contracts. A familiar brand name does not establish the boundary.
Use the gateway, processor and aggregator distinctions to frame the questions, then replace generic role labels with the proposed contract and operating contacts. The decision is about this merchant's service, country, channel and payment methods, not every capability in a provider's portfolio.
In a fictional online homeware shop, the proposed gateway hosts checkout while a separate acquiring arrangement governs merchant settlement. The evaluation must establish how those services join. This example makes no claim about a particular provider's commercial offering.
Build the map around decisions and evidence
| Area | Question to settle before selection | Evidence or acceptance exercise |
|---|---|---|
| Payment credentials | Which party receives, stores or handles the relevant data in this integration? | Actual integration design and responsibility documentation |
| Merchant acquiring | Which entity contracts with the merchant for the acquiring service? | Applicable agreement and supported merchant scope |
| Authorization and capture | Who controls each request and reports its actual result? | Trace a test purchase and the provider-side records |
| Refunds | Who can initiate, investigate and report a refund under this route? | An authorized refund case with references usable by the next team |
| Disputes | Who receives a case, supplies evidence and tracks deadlines? | A scoped walkthrough with the responsible operating teams |
| Reports and payout | Which records explain the merchant's balance and bank credit? | A supported reconciliation example, with timing assumptions identified |
| Incident handling | Who can act when records disagree, including outside normal office hours? | A tested contact and evidence handoff, not just a generic helpdesk address |
The table is a proposed evaluation method. It does not assign responsibilities by industry label. The actual allocation must come from the relevant agreements and supported operating model.
Name the merchant scope and entities providing gateway, acquiring and other relevant services.
Walk authorization, refund, dispute, report and incident cases with the actual proposed teams.
Record a condition against the affected requirement. Resolve it before claiming coverage.
Repeat the failure-handoff checkCompare the supported scope, contractual commitments and merchant responsibilities.
Retain the map, contacts and evidence. Selection alone does not prove the service is live.
Use the actual service contract and demonstrated handoffs to evaluate a provider. A completed responsibility map is preparation for launch, not evidence that processing or support is operational.
Outsourcing does not settle every merchant obligation
The PCI Security Standards Council states that outsourcing all payment processing does not remove a merchant's responsibilities. Its guidance includes checking the provider's applicable compliance scope, documenting responsibilities and confirming the required validation with the appropriate accepting entity.
A hosted integration may change the merchant's exposure and assessment scope, but the exact design matters. Do not convert a provider's compliance statement into a claim that the merchant is certified or has no remaining duties. Compare the actual hosted-checkout and direct-processing boundaries before making that claim.
Evaluate the awkward handoff
Return to the stalled refund. Ask the gateway team which reference it will give the acquirer, what the merchant can see, and who owns the case until the result is established. Ask the acquiring team whether that evidence is sufficient under the proposed arrangement.
If neither party can explain the handoff, record the gap against the affected requirement. An attractive price cannot establish operational coverage that nobody has accepted. Equally, a missing capability in an unrelated market should not disqualify a route that meets the merchant's actual scope.
Keep demonstrated behavior, contractual commitments and unresolved questions in separate columns of the selection record. A provider can be a good fit while still having an explicit condition to resolve before launch. The final choice should tell the merchant who to call, what to send and who remains accountable when a transaction crosses the contract boundary.
Closing thought and further reading
A gateway feature list cannot tell a merchant who will resolve a stalled refund. Test the responsibility map for the actual contracted route.
Ideas that continue the thread.
View all essays
Need help applying this to your business?
Explore practical support for payment operations, product decisions, program delivery and AI automation, grounded in the challenges behind this essay.