Payment Gateway Integration: A Non-Code Selection and Launch Guide
Last updated: August 25th, 2026
Start with a written acceptance plan, not an API key
Define the merchant entity, markets, payment methods, currencies, integration model, lifecycle, controls, owners, tests, and rollback conditions before build work begins. Then shortlist providers, verify each requirement against current evidence, configure and test in a non-production environment, run a limited pilot, and launch only when finance, risk, support, product, and engineering accept the same results.
Payment gateway integration should start with a written acceptance plan, not an API key. Define the merchant entity, markets, payment methods, currencies, integration model, lifecycle, controls, owners, tests, and rollback conditions before build work begins. Then shortlist providers, verify each requirement against current evidence, configure and test in a non-production environment, run a limited pilot, and launch only when finance, risk, support, product, and engineering accept the same results.
This is a non-code selection and implementation process for payment leaders. It does not provide requests, responses, or language-specific instructions.
Use the readiness matrix first. If any market-critical item has no owner, evidence, or pass condition, the project is not ready to move into implementation.
What payment gateway integration includes: five workstreams and one shared acceptance record
Integration is more than connecting a checkout to a provider. It joins the customer payment experience to authorization, authentication, order state, refunds, disputes, reconciliation, settlement, monitoring, and support. A project is complete only when those operating paths work together and the accountable teams can prove it.
Workstream | Required input | Primary owner | Output | Acceptance condition |
|---|---|---|---|---|
Business and market fit | Entity, markets, channels, projected mix | Payment lead | Approved requirement set | Every launch market and method has a documented business reason and owner |
Customer payment experience | Checkout model, authentication, decline and retry policy | Product | Journey and state map | Success, failure, pending, retry, and abandonment states have approved customer behavior |
Technical implementation | Provider documentation, environments, event model | Engineering | Configured integration | Required positive and negative tests pass without duplicate fulfillment |
Risk and security | Data flow, access model, PCI assessment, fraud controls | Security, compliance, risk | Control record | Scope and responsibilities are reviewed by the appropriate internal and external specialists |
Finance and operations | Ledger fields, reconciliation, settlement, refund and dispute operations | Finance and operations | Daily operating procedure | A finance user can explain and resolve a mismatch from order to settlement |
Acceptance record: maintain one evidence register with the requirement, provider response, primary source or contract reference, owner, test result, exception, and approval date. A sales statement without supporting documentation or a written commitment is not acceptance evidence.
Define business, market, and payment requirements with the Readiness Matrix
Copy this selectable table into the project workspace. Use the labels Verified, Conditional, Not verified, or Blocked in the Status column. Treat a market-critical item marked Not verified as a go-live blocker until the provider supplies evidence or the requirement is removed.
Payment Gateway Integration Readiness Matrix
# | Requirement field | Decision or verification question | Owner | Evidence source | Go-live blocker | Rollback requirement |
|---|---|---|---|---|---|---|
1 | Business model | What is sold, to whom, through which channel, and with what billing pattern? | Business owner | Approved launch brief | Yes if the use case is outside provider terms | Preserve the current payment route |
2 | Merchant entity | Which legal entity contracts, receives funds, and owns the customer relationship? | Legal / finance | Entity and contract record | Yes | Retain the current entity route |
3 | Target markets | Which customer locations are in scope for launch and later phases? | Payment lead | Market list | Yes | Disable the affected market |
4 | Required payment methods | Which methods are required, optional, or explicitly out of scope by market? | Product | Method-by-market matrix | Yes for required methods | Fall back to an approved method |
5 | Card schemes | Which schemes must be accepted for the target audience? | Payment lead | Provider documentation and contract | Conditional | Keep an alternative scheme or route |
6 | Presentment currencies | In which currencies will customers see and authorize amounts? | Product / finance | Currency matrix | Yes | Revert to an approved presentment currency |
7 | Settlement currencies | Which currencies and accounts must receive settlement? | Treasury | Contract and settlement documentation | Yes | Retain the current settlement route |
8 | Integration option | Is the chosen model a hosted page, embedded experience, plugin, SDK, or direct API? | Product / engineering | Current provider documentation | Yes | Restore the previous checkout configuration |
9 | Authentication requirements | Where may customer authentication occur, and which outcomes must be handled? | Risk / product | Provider and network documentation | Yes | Route to a supported authentication path |
10 | Capture model | Is immediate or delayed capture required? Is partial capture required? | Product / finance | Written provider confirmation | Yes if unsupported | Use the approved capture path |
11 | Refund flow | Who can initiate full or partial refunds, and how are results confirmed? | Operations / finance | Documentation and test evidence | Yes | Use the approved manual process |
12 | Dispute flow | How are disputes identified, evidenced, assigned, and tracked? | Risk / operations | Contract and operating guide | Yes | Preserve the existing dispute workflow |
13 | Webhook or event requirements | Which events are required, may repeat, or may arrive late or out of order? | Engineering | Event documentation and observed tests | Yes | Switch fulfillment to review mode |
14 | Idempotency requirement | How will retries avoid duplicate payment records or fulfillment? | Engineering | System design and retry tests | Yes | Pause automated retry or fulfillment |
15 | Error and decline handling | Which failures are final, temporary, customer-correctable, or reviewable? | Product / support | Error catalogue and journey map | Yes | Use a safe generic failure path |
16 | Sandbox parity | Which production behaviors cannot be reproduced in the test environment? | Engineering / provider | Test log and provider confirmation | Yes when a critical path is untestable | Limit or postpone the pilot |
17 | Reconciliation fields | Can orders, provider records, refunds, fees, and adjustments be joined reliably? | Finance / data | File or report field dictionary | Yes | Continue the current ledger feed |
18 | Settlement reporting | Are cutoffs, time zones, statuses, adjustments, and delivery methods documented? | Treasury / finance | Reporting guide and sample output | Yes | Retain the current cash forecast process |
19 | Monitoring and alerting | Which missing, delayed, duplicated, or failed events trigger an alert and owner? | SRE / operations | Alert catalogue and drill results | Yes | Move orders to manual review |
20 | Security and PCI scope | Where does payment data travel, and which responsibilities remain with the merchant? | Security / compliance | Data-flow review and PCI guidance | Yes | Disable the new collection path |
21 | Named decision owner | Who can accept a requirement, exception, or residual risk? | Executive sponsor | RACI and approval log | Yes | Escalate; do not launch |
22 | Evidence provenance | Is each capability supported by a current official source, contract, or observed test? | Project manager | Evidence register | Yes for critical claims | Remove the unsupported claim or feature |
23 | Acceptance status | Is the item verified, conditional, not verified, or blocked? | Project manager | Signed gate record | Yes if critical and not verified | Hold at the current gate |
24 | Go-live blocker | What exact condition prevents launch, and who can clear it? | Workstream owner | Blocker register | By definition | Maintain the current route |
25 | Rollback requirement | What will be reversed, who decides, and how will in-flight orders be protected? | Incident owner | Rollback runbook and drill | Yes | Execute the approved rollback |
Matrix exit condition: all launch-critical rows are Verified or have an approved, time-bounded Conditional exception; every blocker and rollback action has a named owner.
Choose an integration model by control, responsibility, and lifecycle needs
The right model is the least complex option that still satisfies the required customer experience and payment lifecycle. Lower development effort never means zero technical work. Even a redirect must be configured, secured, tested, monitored, and reconciled.
Model | Development effort | Checkout control | Security responsibility and PCI scope considerations | Lifecycle and testing | Customization | Maintenance responsibility | Suitable profile | Important limitation |
|---|---|---|---|---|---|---|---|---|
Hosted payment page | Lower relative effort | Lowest; customer moves to a provider-hosted page or flow | Payment-data collection may be more outsourced, but merchant duties remain; confirm eligibility and scope with the acquirer or QSA | Test redirects, return states, abandoned sessions, authentication, callbacks, refunds, and reconciliation | Limited to supported branding and configuration | Provider maintains the payment page; merchant maintains the handoff and order state | Teams prioritizing a faster path to a standard checkout | Less control over layout and some recovery paths |
Hosted fields or embedded checkout | Moderate | More control around provider-controlled payment elements | Scope depends on how all payment-page elements, scripts, and frames are delivered; do not assume a hosted page and an embedded form have identical eligibility | Add browser, device, script-integrity, frame, event, authentication, and failure tests | Moderate to high within component constraints | Shared; provider maintains components, merchant maintains the surrounding page | Teams needing an on-site experience without owning every payment field | Third-party scripts or frames can create additional security and availability dependencies |
Ecommerce plugin | Lower to moderate when the platform and version are supported | Constrained by plugin and platform | Merchant must secure the store, plugin, access, and configuration; scope still requires review | Test platform version, theme conflicts, upgrades, all lifecycle states, events, refunds, and reporting | Low to moderate | Provider or vendor maintains the plugin; merchant owns platform compatibility and updates | Standard stores with a supported platform and limited custom flow | Version lag, extension conflicts, and lifecycle gaps can become blockers |
Mobile or web SDK | Moderate to high | High within the SDK design | Merchant owns app integration, release security, data flow, storage decisions, and update process | Test supported operating systems, app states, authentication handoffs, network loss, version changes, and events | High within SDK boundaries | Shared; merchant must track SDK releases and app-store rollout | Product teams with native or complex client experiences | Release cycles and deprecated versions add ongoing work |
Direct API integration | Highest | Highest | Merchant takes broader design and operational responsibility; handling card data can materially change PCI obligations | Test authentication, signing, retries, duplicate handling, state transitions, callbacks, reconciliation, refunds, disputes, and recovery | Highest | Merchant owns more orchestration and must track API changes | Teams needing a custom lifecycle and able to operate it continuously | Greater build, security, testing, and maintenance burden |
Decision rule: reject any model that cannot prove a required lifecycle state. Among the remaining models, choose the one with the lowest combined customer-experience, control, security, operations, and maintenance burden—not simply the shortest build estimate.
Source: PCI SSC explains that SAQ A eligibility differs for redirect and embedded payment forms and that outsourcing payment functions does not remove every merchant responsibility.[12][13][14]
Build a provider-selection scorecard with evidence and kill gates
Customize the suggested weights before reviewing providers; changing them after seeing a favored vendor creates selection bias. Score each criterion from 0 to 5, multiply by its weight, and attach evidence. A high total cannot override a kill gate.
Criterion | Suggested weight | Evidence required | Example kill gate |
|---|---|---|---|
Entity and target-market eligibility | 15 | Written onboarding and contract eligibility | Required entity or launch market is not supported |
Required payment methods and schemes | 15 | Current method-by-market documentation | A launch-critical method is absent or unverified |
Integration-model fit | 10 | Current technical documentation and architecture review | Required model or platform is not documented |
Lifecycle completeness | 15 | Authorization, authentication, capture, refund, dispute, and event evidence | A required state cannot be represented or recovered |
Security and compliance fit | 15 | Data-flow review, provider evidence, internal specialist decision | Residual risk has no accountable approver |
Reliability and recovery | 10 | Retry, duplicate, timeout, status-recovery, and incident evidence | Payment outcome can remain unknowable to operations |
Reconciliation and settlement operations | 10 | Sample reports, field dictionary, timing, and finance test | Finance cannot join orders to provider and settlement records |
Commercial and contract fit | 10 | Applicable quote and contract terms | Contract terms conflict with the approved business case |
Selection output: a scored shortlist, a disqualification log, unresolved questions, and a written recommendation. Keep detailed fee modeling on the payment gateway fees guide so this page remains focused on integration selection and implementation.
Map the complete payment lifecycle before building
Draw the lifecycle as merchant states, provider states, customer messages, events, and finance records. Do not treat the browser return page as final payment evidence; the reliable source and recovery behavior must be defined for the selected provider.
Lifecycle state | Product question | Engineering record | Operations or finance acceptance |
|---|---|---|---|
Order created | When is the amount and currency fixed? | Immutable internal order identifier and amount | Order can be located before payment starts |
Payment initiated | Can a customer retry or change method? | One attempt record per initiation | Multiple attempts remain linked to one order |
Authentication | What happens on frictionless, challenge, failure, or abandonment? | Authentication outcome and correlation | Support can distinguish authentication from payment failure |
Authorization | Which outcomes are final, pending, or recoverable? | Provider reference, state, reason, timestamp | Customer and order messages match the known state |
Capture | Is capture immediate, delayed, full, or partial? | Capture request and result linked to authorization | Finance can distinguish authorized from captured funds |
Asynchronous event | Which state changes arrive later? | Durable event receipt, deduplication, processing result | Late or repeated events do not duplicate fulfillment |
Refund | Are full and partial refunds required? | Refund record, amount, state, provider reference | Operations can trace request to final financial result |
Dispute | How is a dispute discovered and assigned? | Case reference, deadline, amount, evidence state | Risk and finance have an owned response workflow |
Reconciliation | What source resolves mismatched internal and provider states? | Join keys, field mapping, exception queue | Every mismatch has a reason or an owner |
Settlement | How are paid amounts, adjustments, fees, and transfers represented? | Settlement record and ledger mapping | Treasury can trace expected to received funds |
Lifecycle exit condition: every state has one system of record, one recovery path, one customer or operator message, and one accountable owner. Partial capture, partial refunds, dispute notifications, and similar functions stay as provider-verification items until documented and tested.
Source: EMVCo describes frictionless and challenge flows for EMV 3-D Secure; it does not justify assuming a particular approval or liability outcome.[15][16]
Assign roles and approval gates before implementation
A single project owner coordinates the work, but no one role can approve every risk. Use the following assignment as a starting point.
Role | Owns | Must approve before pilot | Must approve before full launch |
|---|---|---|---|
Executive sponsor | Business case, residual-risk escalation | Scope and pilot exposure | Final unresolved exceptions |
Payment lead | Requirements, provider selection, gate record | Provider and model recommendation | Cross-functional acceptance |
Product | Checkout, customer states, recovery messages | Journey and edge cases | Pilot behavior and support feedback |
Engineering | Architecture, state handling, environments, recovery | Build and end-to-end test evidence | Reliability, rollback, and operating handoff |
Security / compliance | Data flow, access, PCI and control review | Approved security design | Remediations or accepted residual risks |
Risk / fraud | Authentication, fraud controls, disputes | Risk test scenarios | Pilot risk performance and operations |
Finance / treasury | Reconciliation, settlement, ledger, refunds | Sample records and mapping | Production reconciliation and cash checks |
Support / operations | Procedures, tools, escalation, customer messaging | Runbook and training | Pilot incident handling and staffing |
SRE / incident owner | Monitoring, alerting, response, rollback | Alert and rollback drill | Launch coverage and escalation readiness |
Gate rule: each approver signs the evidence relevant to their responsibility. Silence, meeting attendance, or an unresolved comment is not approval.
Follow a nine-stage Payment Gateway Integration Stage-Gate Flow
Stage | Required input | Accountable owner | Exit condition | Typical blocker |
|---|---|---|---|---|
1. Define business and market requirements | Launch brief, entity, markets, methods, currencies | Payment lead | Readiness Matrix scope rows approved | Entity, market, or required method is unclear |
2. Choose the integration model | Checkout journey, control needs, team capacity, security constraints | Product | Model decision and rejected alternatives documented | Required lifecycle cannot be supported by the model |
3. Shortlist providers | Requirements, provider evidence, scorecard | Payment lead | Shortlist and disqualification log approved | Evidence relies only on a sales statement |
4. Validate commercial and compliance fit | Applicable quote, contract, data flow, risk review | Legal / compliance | Contract and control exceptions have owners | Scope, terms, or residual risk is unacceptable |
5. Design the payment lifecycle | State model, customer journeys, finance and support needs | Product | State, event, recovery, and ownership maps approved | Pending, duplicate, refund, or dispute paths are missing |
6. Build and configure | Approved design, environments, credentials, access, documentation | Engineering | Implementation review complete; no critical design blocker | Test and production configuration is confused or insecure |
7. Test end to end | Test plan, scenarios, observability, sample reports | QA / engineering | Positive, negative, recovery, finance, and rollback tests pass | Sandbox cannot reproduce a critical behavior and no alternative proof exists |
8. Pilot and monitor | Limited exposure plan, alerts, support and finance coverage | Payment lead | Pilot criteria met; incidents and mismatches resolved | Outcome, event, or settlement cannot be observed reliably |
9. Launch with rollback readiness | Signed gate record, runbooks, monitoring, trained owners | Executive sponsor | Launch accepted; rollback remains executable | Critical exception, missing owner, or failed rollback drill |
Each gate produces a record. If the next stage starts before the prior exit condition is met, mark the exception, owner, exposure, expiration, and rollback trigger explicitly.
Test end to end with negative, duplicate, recovery, and finance scenarios
The test plan must prove what happens when the ideal path breaks. Run it against the selected model and provider documentation; where a capability is unverified, test planning starts with written provider confirmation.
End-to-End Payment Integration Testing Map
Test | Owner | Setup or trigger | Pass condition | Capability boundary |
|---|---|---|---|---|
Successful payment | QA / product | Provider-supported success scenario | Customer, order, provider, event, and finance states agree | Required for launch |
Declined payment | QA / product | Provider-supported decline scenario | No fulfillment; clear customer recovery; reason is recorded safely | Required for launch |
Authentication-required payment | Risk / QA | Supported challenge scenario | All return, failure, abandonment, and final payment states are handled | Verify supported 3-D Secure scenarios |
Timeout | Engineering | Interrupt or delay the response within approved test methods | No false success; outcome is recovered without unsafe duplicate action | Required for launch |
Duplicate request | Engineering | Submit a documented duplicate scenario | One commercial action and one fulfillment outcome | Do not assume provider protection; prove merchant behavior |
Idempotent retry | Engineering | Retry after an ambiguous or interrupted attempt | Retry converges on one outcome without duplicate fulfillment | Verify provider mechanism; merchant system still needs a safe rule |
Partial capture | Product / finance | Use only after written capability confirmation | Captured and remaining amounts reconcile correctly | Provider confirmation required |
Full and partial refund | Operations / finance | Use documented refund scenarios | Amounts, states, events, ledger, and customer communications agree | Confirm each refund type separately |
Webhook duplication and ordering | Engineering | Repeat and reorder events using supported test controls | Processing is deduplicated; state does not move backward incorrectly | Verify provider delivery behavior |
Missing webhook | Engineering / operations | Withhold or delay an event using approved controls | Monitoring fires and an authoritative recovery path resolves the order | Required for launch |
Currency and amount precision | Finance / QA | Test every launch currency and rounding boundary | Customer, order, provider, refund, report, and ledger amounts match | Required per currency |
Reconciliation | Finance | Compare a controlled set of orders and lifecycle changes | All records join; differences enter an owned exception queue | Verify report fields and delivery |
Settlement report | Treasury | Review a sample or controlled production-pilot report | Statuses, cutoffs, currency, adjustments, and transfer references are understood | Verify contract-specific reporting |
Dispute notification | Risk / operations | Use provider-supported test or documented walkthrough | Notification, deadline, assignment, evidence, and finance impact have owners | Provider confirmation required |
Monitoring alert | SRE / operations | Trigger each defined failure signal | Correct owner receives a useful alert and follows the runbook | Required for launch |
Rollback | Incident owner | Run a controlled rollback drill | New attempts use the safe route; in-flight orders remain recoverable and auditable | Required for launch |
Test acceptance: attach the environment, provider documentation version, scenario, expected result, observed result, record identifiers, date, and approver. Screenshots alone are insufficient if they cannot be joined to the underlying order and finance records.
Ask precise security, authentication, and compliance questions
Treat this section as a review agenda, not a compliance conclusion. Your actual scope depends on architecture, provider arrangement, merchant environment, and the assessment path agreed with the relevant specialists.
Review question | Owner | Acceptance evidence |
|---|---|---|
Which party serves every payment-page element and script? | Security | Current data-flow and page-source review |
Does the flow redirect, embed a provider form, or collect payment data directly? | Security / engineering | Architecture diagram tied to the deployed configuration |
Which PCI DSS validation path applies to this merchant and integration? | Compliance | Written determination from the appropriate acquirer, QSA, or qualified internal process |
Which merchant responsibilities remain after outsourcing payment functions? | Compliance / security | Control owner list and operating evidence |
Where are credentials and signing keys created, stored, rotated, and logged? | Security / engineering | Access, storage, rotation, and incident procedures |
How are test and production credentials and access separated? | Engineering / security | Environment inventory and access test |
Which EMV 3-D Secure flows and outcomes can occur? | Risk / product | Provider and EMVCo-aligned journey map plus supported tests |
What happens when authentication completes but the payment result is delayed? | Product / engineering | State and recovery test |
PCI SSC specifically distinguishes redirect and embedded payment-form conditions for SAQ A eligibility and warns that outsourcing does not eliminate all obligations. Confirm scope for the deployed implementation; do not infer it from a model label alone.[12][13][14]
EMVCo describes frictionless and challenge flows as primary EMV 3-D Secure paths. Design customer states for both, but verify the actual provider configuration and outcomes before launch.[15][16]
Prove reconciliation, settlement, and operational readiness
Finance acceptance is part of integration acceptance. A successful checkout is not enough if operations cannot explain the money later.
Operational control | Required evidence | Acceptance test | Owner |
|---|---|---|---|
Join keys | Order, attempt, provider payment, refund, dispute, and settlement identifiers | Trace a sample from order through final financial record | Finance / data |
Amount and currency | Presentment, authorized, captured, refunded, adjusted, and settled values | Recalculate controlled examples under the documented currency rules | Finance |
Status mapping | Provider states mapped to internal order and ledger states | Review every final, pending, and reversible state | Product / finance |
Report delivery | File or report format, availability, cutoff, time zone, and retention | Retrieve and process a sample without manual reinterpretation | Finance engineering |
Exception queue | Missing, duplicate, amount, currency, status, and timing differences | Assign, resolve, and close seeded exceptions | Operations |
Settlement interpretation | Gross amounts, adjustments, applicable fees, net amounts, and transfer references | Match an accepted sample to the bank or settlement account | Treasury |
Refund and dispute accounting | Lifecycle, timing, references, and ledger treatment | Trace a controlled refund and documented dispute workflow | Finance / risk |
Close procedure | Daily owner, escalation, aging, evidence, and sign-off | Run the procedure during pilot and record unresolved items | Finance operations |
Before provider selection, inspect the broader international payment gateway guide. For fee categories and quote questions, use the dedicated payment gateway fees guide.
Pilot, monitor, and preserve a tested rollback path
Limit the pilot by a dimension the team can observe and reverse, such as a market, method, channel, or controlled traffic allocation. Set thresholds from your own baseline and risk appetite; this guide does not invent universal launch numbers.
Pilot control | Before pilot | During pilot | Exit or rollback decision |
|---|---|---|---|
Exposure | Define included traffic and exclusions | Confirm routing matches the plan | Stop if exposure exceeds the approved boundary |
Payment-state accuracy | Approve expected state transitions | Compare internal and provider outcomes | Roll back if outcome ambiguity cannot be recovered safely |
Duplicate protection | Pass duplicate and retry tests | Watch duplicate attempts and fulfillment | Pause automation on any unexplained duplicate commercial action |
Event health | Define delivery and processing signals | Monitor missing, late, repeated, and failed events | Move affected orders to recovery or review |
Customer experience | Approve messages for every state | Review abandonment, decline, support, and complaint patterns | Roll back a broken or misleading journey |
Finance controls | Validate sample reports and joins | Reconcile each pilot period | Hold expansion while unexplained differences remain |
Support and incident response | Train owners and test escalation | Record contacts, causes, and recovery time | Roll back if coverage or recovery is inadequate |
Rollback execution | Approve configuration, data, and in-flight-order steps | Keep the safe route ready | Incident owner decides using documented triggers |
Pilot exit condition: the pilot meets the team’s predeclared customer, risk, engineering, finance, and support criteria; all material incidents have a cause and disposition; the rollback path is still viable.
Fix common integration failures by repairing the missing control
Failure | Why it happens | Immediate containment | Durable fix | Acceptance evidence |
|---|---|---|---|---|
Requirements arrive during build | Selection began before markets, methods, or lifecycle were agreed | Freeze new scope and classify blockers | Complete the Readiness Matrix and gate changes | Approved requirements and change log |
Sandbox success is treated as production proof | Environment differences are not recorded | Limit the pilot | Maintain a parity-gap register and production-safe validation plan | Each gap has evidence, owner, and test |
Success page triggers fulfillment | Browser navigation is mistaken for authoritative payment state | Hold affected fulfillment for review | Use the documented authoritative state and recovery path | Delayed and abandoned-return tests pass |
Retries create duplicates | Ambiguous outcomes have no idempotent business rule | Pause automated retries | Define deduplication keys, retry ownership, and reconciliation | Duplicate and interrupted-retry tests pass |
Repeated or out-of-order events corrupt state | Event handling assumes exactly-once, ordered delivery | Quarantine conflicting events | Make processing deduplicated and prevent invalid backward transitions | Duplicate and ordering tests pass |
Missing events leave orders pending | No recovery source or alert exists | Run the approved status-recovery process | Add monitoring, recovery, aging, and escalation | Missing-event drill closes correctly |
Refunds or disputes are added after launch | The project modeled only purchase success | Restrict unsupported operations | Add full lifecycle requirements, ownership, and tests | Operations and finance sign off |
Amounts fail to reconcile | Currency precision, joins, or adjustment fields were not validated | Stop automated close for affected records | Publish a field dictionary and exception workflow | Controlled orders reconcile end to end |
Monitoring says the service is up while payments fail | Infrastructure health is not payment-state health | Use business-state checks | Alert on outcome, event, order, and reconciliation signals | Alert drills reach the correct owner |
Rollback loses in-flight orders | Routing reversal was designed without state recovery | Stop new exposure and inventory open attempts | Add in-flight classification and post-rollback recovery | Rollback drill preserves every test order |
Community discussions repeatedly describe sandbox gaps, duplicate charges, missing or repeated webhooks, and recovery paths as the difficult part of payment integrations. Those accounts are useful for scenario discovery, not as proof of a provider capability; every final requirement still needs current primary evidence and observed testing.
Where HaiPay may fit, based on current documented integration patterns
HaiPay may be worth evaluating when a team wants to compare a provider-hosted payment URL, a documented embedded JavaScript checkout pattern, or a direct API integration. The current source set also documents separate test and production application identifiers and keys, IP allowlisting, request signing, a test environment, asynchronous payment notifications, merchant-side idempotent handling, international USD card refund flows, and reconciliation outputs.[1][2][3][4][5][6][7][8]
Use those facts as shortlist evidence—not as automatic fit. Validate the exact entity, market, payment method, currency, lifecycle, configuration, report, contract, and production behavior for your project.
Requirement | Current evidence reviewed | Selection action |
|---|---|---|
Hosted flow | Checkout and card documentation describe a hosted payment page or payment URL | Confirm fields, branding, return behavior, lifecycle, and eligible methods for the target setup.[8][9] |
Embedded flow | Card documentation describes a JavaScript-based embedded mode | Review deployed data flow, browser behavior, security responsibilities, supported methods, and PCI scope.[8] |
Direct API | HaiPay’s current integration guide describes direct API integration | Review security, lifecycle, events, recovery, reports, and team operating capacity.[2][3][4] |
Environment separation | Documentation says test and production application identifiers are independent | Prove configuration separation and access controls before pilot.[4][6] |
Test controls | HaiPay documents a test environment and an end-to-end testing tool that can drive test order status and notifications | Map each required scenario to a supported test, provider walkthrough, or controlled pilot proof.[5] |
Notifications and duplicates | HaiPay documents asynchronous notifications, retry behavior, possible duplicates, and a merchant idempotency responsibility | Test repeated, delayed, failed, and recovered notification processing.[6][7] |
Card refunds | Current card documentation describes full and partial refund paths | Confirm eligibility, permissions, states, reporting, and contract terms; test both separately.[8] |
Reconciliation | Current common API documentation describes reconciliation files and report functions | Obtain sample fields and prove order-to-report-to-ledger joins.[7] |
For the official product paths, review HaiPay API Integration, HaiPay Checkout, credit-card acceptance, local payment methods, and the current HaiPay documentation. Evaluate applicable commercial terms on HaiPay Pricing, then request project-specific confirmation through HaiPay Contact.
Source: HaiPay official product and technical documentation, verified August 21, 2026.[1]–[11]
Where HaiPay is not yet a confirmed fit
The reviewed source set does not establish every possible integration requirement. If the project depends on an off-the-shelf ecommerce plugin, a specific native mobile or web SDK, hosted fields as a distinct product, partial capture, or a particular dispute-notification mechanism, mark that requirement as Not verified in the working matrix and obtain current written evidence before selection. Do not convert absence from this review into a claim that the capability does not exist.
Dependency | Evidence status in this review | Required next step | Blocker rule |
|---|---|---|---|
Specific ecommerce plugin and platform version | Not established | Request the supported platform, version, owner, lifecycle coverage, and update policy | Block if the plugin is the approved integration model |
Native mobile or web SDK | Not established in the technical index reviewed | Request current SDK documentation, support policy, release history, and required lifecycle coverage | Block if a native SDK is mandatory |
Hosted fields as a distinct option | Not established | Request exact architecture and security documentation | Block if embedded fields are required |
Provider-side request idempotency contract | Not established; current documentation requires merchant-side idempotent callback handling but does not establish replay semantics for payment requests | Request the provider’s current duplicate-request, retry, deduplication, and outcome-recovery contract | Block if automated safe retry depends on provider-side idempotency |
Partial capture | Not established | Request current capability and test documentation | Block if the business model requires it |
Dispute notification mechanism | Not established | Request workflow, notification, deadline, report, and test evidence | Block until risk and operations accept a workable process |
After reviewing the evidence, decide whether the provider meets the project requirements, can meet them only under specific conditions, or should be excluded. Document the evidence behind each condition and assign an owner to resolve it. General product claims should not override an unresolved project requirement.
Sources and verification record
The product and technical sources below were accessed on August 21, 2026. Capabilities remain subject to the merchant entity, market, configuration, method, contract, and current documentation.
- HaiPay, Integration Process Guide.
- HaiPay, Direct API Integration Guide.
- HaiPay, API Description Guide.
- HaiPay, Configuration Settings and Signature Rules.
- HaiPay, End-to-End Testing.
- HaiPay, Onboarding Checklist.
- HaiPay, Common API Documentation.
- HaiPay, International Card Documentation, Refund Apply, and Refund Query.
- HaiPay, Checkout.
- HaiPay, API Integration.
- HaiPay, Credit Card.
- PCI Security Standards Council, FAQ 1588: SAQ A eligibility for embedded payment forms.
- PCI Security Standards Council, FAQ 1604: SAQ A merchant responsibilities.
- PCI Security Standards Council, FAQ 1438: SAQ A payment-page elements.
- EMVCo, Optimising Online Payment Authentication with EMV 3-D Secure.
- EMVCo, EMV 3-D Secure White Paper: Introduction.
Editorial disclosure: HaiPay is the publisher and a payment-service provider. This guide separates generic selection criteria from documented HaiPay patterns, records important limitations, and does not replace legal, compliance, security, tax, or contractual advice. Validate the deployed integration and applicable terms before launch.
FAQ
Start by defining the entity, markets, methods, currencies, checkout model, lifecycle, risk controls, reports, owners, and rollback conditions. Shortlist providers with evidence, validate contract and compliance fit, design states and recovery, configure the selected model, run positive and negative end-to-end tests, pilot with monitoring, and launch only after cross-functional acceptance. Code is one implementation activity inside that process, not the starting point.
