ONLINE PAYMENT OPERATIONS
Paid at checkout is only the first status. The order, refund and settlement still need to make it through the business.
When the gateway approves a card but the order stalls, a refund loses its original tender or nobody owns the plugin, your team is left repairing a sale that looked finished. Trace the full path before changing the checkout, gateway or API.
See How the Review Works
HOW THE ORDER MOVES
Start with the order that made your team open three systems.
Follow one real checkout from customer intent through fulfillment, settlement and a refund. The useful answer is the one that keeps the same order explainable when something goes wrong.
WHAT MUST NOT BREAKA successful checkout should not create an order that fulfillment cannot identify, a refund that loses the original tender, or a settlement the business cannot reconcile.
THREE ONLINE PAYMENT NEEDS
Hosted collection, ecommerce checkout and custom connections solve different order problems.
Remote collection without a full cart
For payment links, invoices or hosted forms where the business needs a controlled payment step and a clear posting record.
Cart, order and fulfillment stay connected
For product sales where pricing, inventory, shipping or pickup, customer notices and refunds must follow the same order.
Technical control has a real owner
For supported integrations that require clear responsibility for authentication, tokenization, testing, monitoring, version changes and incident support.
THE STRESS TEST
A refund tests more of the system than a successful checkout.
Trace the original cart, authorization, order, fulfillment state, customer notice, refund request, processor response and settlement adjustment. The exact connections and timing require verification.
ORIGINAL ORDERItems, total and customer
PAYMENTGateway and tender reference
FULFILLMENTShipped, picked up or cancelled
REFUND / SETTLEMENTReversal, deposit and accounting
WHERE THE DECISION BREAKS
Catch the checkout break before it reaches fulfillment or settlement.
Payment succeeds; order stalls
The gateway approves the transaction but the order never reaches the correct fulfillment queue.
Refund loses the original context
The team can return money but cannot reliably match the tender, item, inventory or customer notice.
Technical ownership is unclear
The cart, plugin, gateway, processor and developer each assume another party owns monitoring or recovery.
REAL PLATFORM EVIDENCE
Gateway capability grounded in the system DATA ONE actually works with.
The operating relationship and the product capability are separate facts. Exact merchant setup, processor, services, credentials and implementation still require verification.
AUTHENTIC SCREEN REQUIREDPrivate evidence holdNo recreated or generated vendor interface is shown.
NMI PAYMENT GATEWAY · MERCHANT CENTRAL
Gateway, hosted checkout and API paths—kept distinct from merchant boarding.
DATA ONE’s internal operating material identifies the NMI Gateway as the payment gateway used for merchant transaction setup and reporting, and Merchant Central as the separate merchant application and activation system. Official NMI material documents hosted pages, payment components, APIs and transaction reporting.
Official source: nmi.com and docs.nmi.com · retrieved 2026-09-19 · public interface-image reuse rights not confirmed · exact account, services and configuration to verify.WHAT A REVIEW COVERS
The fastest way to find the break is to trace one online order end to end.
MERCHANT INPUT
Trace one online order end to end
Bring the checkout receipt, gateway or processor record, fulfillment event, refund, settlement report and technical ownership map.
DATA ONE WORK
Align customer, technical and operating owners
Map the cart, gateway, processor, order, fulfillment, refund and support responsibilities around the same sale.
NEXT STEP
Repair the exact break
Document what can stay and what evidence is required before changing the checkout, gateway or API.
You leave knowing which checkout, gateway or ownership question to test next. Exact compatibility and implementation still require confirmation.
QUESTIONS BEFORE DECISIONS
Can the checkout, order and settlement answer these six questions?
Is online payment the same as an ecommerce checkout?
Not always. A hosted payment link or remote invoice may collect payment without a cart, while ecommerce usually connects the cart, checkout, order, fulfillment, refund and settlement records.
Do we need a custom gateway or API?
Only when the business has a defined technical requirement that a supported hosted or prebuilt connection cannot meet. Confirm ownership, authentication, tokenization, testing, monitoring and support before choosing custom work.
What should happen after checkout approves the payment?
The approved payment should update the correct order, customer notice, fulfillment status, refund reference and settlement record. The exact behavior depends on the selected platform and configuration.
How should online refunds be tested?
Start with the original order and tender, issue a full or partial refund, confirm the customer notice, inventory or fulfillment effect, processor record and accounting result. Timing and availability vary.
Can an existing website keep its current cart?
Often, yes. Review the cart, gateway, processor, plugins, token ownership, checkout behavior and support lifecycle before deciding what can stay, connect or change. Compatibility must be verified.
What should we bring to an online-payments review?
Bring one completed order from cart through authorization, fulfillment, refund and settlement, plus the current gateway, processor, plugins, reports and ownership responsibilities. Remove sensitive credentials before sharing.
DISPUTE AND FRAUD PROTECTION
Treat checkout and dispute handling as different control points.
Online orders can create criminal fraud, merchant-error disputes or first-party misuse after fulfillment. Authentication, order detail, pre-dispute alerts and representment act at different points, so they should not be treated as one feature. Review the actual dispute sources before adding controls. See Chargeback & Fraud Protection
A clear next step