Payment Flow Fundamentals

This page introduces the different payments method and what to consider when choosing a payment method for your business.

Before starting integration, it’s important to understand how crypto payments differ from traditional payment methods such as card payments, local bank transfers, or e-wallets.

Most traditional payment systems follow a synchronous flow, where the payment is confirmed instantly and the result is returned in a single interaction. Crypto payments, however, follow an asynchronous flow, where confirmation may take time, and the transaction is only finalized once confirmed on-chain and processed by Orbital.

Synchronous Payments (Traditional)

Synchronous payments operate in a linear and time-bound manner. A user initiates a payment (e.g. via card), is redirected to a hosted page or processor, and receives a success or failure result within the same flow.

In this model:

  • The merchant creates a transactionId or orderId before initiating the payment.
  • The result (success or failure) is known immediately.
  • Based on this result, the user’s balance is credited or the payment is marked as failed.

This model works well for instant feedback systems but is not optimal for crypto payments due to network latency, confirmations, and the potential for manual errors (e.g. underpayment, overpayment, or wrong currency).

Asynchronous Payments (Crypto)

Crypto payments are asynchronous by design. There is no guarantee of real-time confirmation. The transaction must be created, sent, and confirmed on the blockchain each step happening outside of a single session flow.

In this model:

  • The merchant generates a wallet address (or time-bound invoice) and assigns it to a user.
  • The user independently sends funds to this address from their crypto wallet.
  • Orbital monitors the blockchain and notifies the merchant via a webhook once a valid deposit is detected.
  • The merchant should create or update a transaction record upon receiving this notification and determine whether to credit the user, based on the status and amount received.

This asynchronous model allows for greater flexibility but requires more careful handling of callbacks, reconciliation logic, and user-facing communication.