Insights on Crypto Payments, Infrastructure, and Operations
Crypto Payment ToolsPayment Operations

OxaPay · Crypto Payment Tools

Payment Status and Exception Simulator

Test 15 crypto payment scenarios, merchant order decisions, partial payments and webhook delivery without sending funds.

Core principle

Payment status and order status are related, but they are not the same record

The payment gateway reports what happened to the payment. Your application decides what happens to the order. A reliable integration never fulfills from an unverified callback, never moves an order backward after a later event, and never treats an amount exception as a normal paid order without an explicit policy.

Before you begin This simulator applies documented payment rules to a fictional order.

It helps you understand likely status transitions and merchant actions. It does not create a payment, call an endpoint, validate a real transaction, or replace Payment Information.

RULE-BASED EDUCATIONAL MODEL
Simulation mode

Start with a simple business scenario or inspect every operational variable.

Ready-made scenarios Select one to load realistic values instantly.
Quick Simulation

Test a payment situation in seconds

Choose a scenario and adjust only the details most merchants need.

5 simple inputs
No technical setup required

The simulator fills the webhook, order-state, confirmation, and policy settings for you. Open Advanced Configuration to inspect or change them.

01 Choose and adjust
Simulation output

Expected status and merchant action

Results update when you run the scenario.

paid
Simple answer

Payment complete — the order can be delivered

The customer paid enough within the payment window.

Recommended action: fulfill the order once and record the payment.
Gateway status paid

Confirmed value satisfies the acceptance threshold.

Order decision Fulfill

The payment reached the required terminal state.

Amount classification Exact

Received amount equals the requested amount.

Delivery outcome Accepted

The callback is valid and the handler returns 200 with ok.

Threshold math

Amount decision

Minimum accepted: 99.00 USD
Received: 100.00 USD Difference: 0.00 USD
Event progression

Payment timeline

    Operational review

    Exceptions and controls

    Webhook model

    Delivery attempts and illustrative payload

    2 events

    Illustrative simulated payload — fields may differ from a live response.

    Implementation rule

    Recommended handler logic

    How to use this payment status simulator

    This payment status and exception simulator helps merchants and developers understand how a payment event should affect an order. Select a ready-made scenario or set the amount, expiry, network confirmations, payment flow and webhook behavior. The simulator is educational: it neither checks a real transaction nor contacts OxaPay.

    Payment status is not order status

    The payment gateway reports the payment state; your store or platform independently decides whether to keep an order pending, deliver goods, or initiate a review. A detected transfer is not automatically an accepted payment. Only a verified, permitted final state should initiate irreversible fulfillment. Duplicate or out-of-order webhooks must not trigger repeated fulfillment.

    How amount exceptions and timing are modelled

    The accepted shortfall is calculated from the requested amount and the configured underpayment coverage. An excessive shortfall, late transfer, or unsupported payment flow requires a business policy rather than automatic delivery. Static Address deposits require separate customer and transaction matching. Zero network confirmations are not a substitute for a provider-reported final status.

    Webhook delivery and recovery

    The simulated webhook cases include duplicates, invalid HMAC signatures, out-of-order events, a failed first attempt, and exhausted retries. A merchant handler should validate the original raw-body signature, identify the order by reference, apply idempotent updates and verify disputed records using Payment Information or Payment History. Never trust an illustrative JSON payload as a live API response.

    Limits of the simulation

    All orders, transaction hashes, timestamps and payloads shown here are fictional. Actual OxaPay statuses, limits, callbacks and retry schedules may change. Check the current official documentation before building or changing production logic. The tool sends no payments, refunds, real webhooks or private credentials.

    Documented OxaPay payment statuses

    The accepted shortfall is calculated from the requested amount and the configured underpayment coverage. An excessive shortfall, late transfer, or unsupported payment flow requires a business policy rather than automatic delivery. Static Address deposits require separate customer and transaction matching. Zero network confirmations are not a substitute for a provider-reported final status.

    new
    Invoice created; payment currency not selected.
    waiting
    Payment currency selected; waiting for payment.
    paying
    A payment attempt or transaction is being processed.
    paid
    The invoice has been fully paid.
    manual_accept
    The merchant manually accepted the invoice.
    underpaid
    A partial payment did not fully satisfy the invoice.
    refunding
    A refund has been initiated.
    refunded
    The payment has been refunded.
    expired
    The invoice was not paid within its lifetime.

    Current OxaPay documentation

    Review the current payment status table, invoice parameters, payment lookup and webhook integration.