<!-- tempo-docs-context -->
> Source: [/docs/resources/guides/stablecoin-payment-infrastructure-enterprise-scale](https://tempo.xyz/developers/docs/resources/guides/stablecoin-payment-infrastructure-enterprise-scale.md)
> Section: [Get Started](https://tempo.xyz/developers/get-started.md). Choose a starting point, send a test payment, get testnet funds, connect a coding agent, find the SDKs and CLI, and use the resource guides to plan payment workflows, liquidity, provider selection, and partner integrations.
> [Documentation index](https://tempo.xyz/developers/llms.txt) · [Docs skill](https://tempo.xyz/developers/SKILL.md)

> Tempo MCP: Use `search`, `find_pages`, `read_page`, and `code` at `https://mcp.tempo.xyz` for Tempo and related documentation.
> If an indexed page is missing or reflects an older site, read this site’s [documentation index](https://tempo.xyz/developers/llms.txt) and Markdown pages directly.

[Guides](https://tempo.xyz/developers/docs/resources/guides) / [Payment infrastructure](https://tempo.xyz/developers/docs/resources/guides#payment-infrastructure) / Evaluate enterprise payment infrastructure

# Evaluate enterprise payment infrastructure

Enterprise stablecoin payment infrastructure combines settlement, accounts and signing, liquidity, controls, funding and payouts, and finance records. Assign each responsibility before selecting providers. Use the [payments implementation guides](https://tempo.xyz/developers/docs/guide/payments) for transaction submission and verification.

At production volume, payment costs, delivery evidence, exceptions, and finance integration become product requirements. A network capability is useful only when the application and its providers can operate the complete flow.

## Assign responsibility across the payment stack

| Layer | Decisions to make |
| --- | --- |
| Settlement | Exact network and asset, finality signal, capacity, fees, and observed delivery evidence. |
| Accounts and signing | Who controls funds, approves payments, manages keys, and recovers access. |
| Issuance and liquidity | Issuer terms, redemption access, supported assets, conversion, and required balances. |
| Risk controls | Onboarding, screening decisions, token policies, account permissions, monitoring, and reporting. |
| Fiat access | Funding and local delivery providers, coverage, limits, timing, and exceptions. |
| Reporting | Business references, event ingestion, ledger mapping, reconciliation, and support records. |

A provider may supply several layers, but verify the exact service and contractual model. A fiat interface alone does not establish who owns funds or which operating obligations remain with your business.

## Distinguish a gateway from the settlement network

A gateway connects checkout to payment processing. The settlement network records the onchain transfer. Establish which responsibilities the service supplies and which remain in your application.

| Responsibility | Evidence to request |
| --- | --- |
| Checkout | Supported wallets, networks, token contracts, request formats, and expiry behavior. |
| Confirmation | Actual receipt checks, missed-event recovery, and prevention of duplicate fulfillment. |
| Funds management | Signing authority, balance ownership, fee funding, custody, and conversion. |
| Exceptions | Underpayments, held transfers, refunds, delayed delivery, and failed bank payouts. |
| Finance integration | Stable identifiers, export or API fields, and ownership of the ERP mapping. |

For example, a correctly referenced transfer can arrive while the order system is unavailable. The integration must recover the event and fulfill once. Near-instant settlement does not supply that recovery process. Follow the [receiving guide](https://tempo.xyz/developers/docs/guide/payments/accept-a-payment) for verification and event identifiers, then use the [acceptance planning guide](https://tempo.xyz/developers/docs/resources/guides/how-to-accept-stablecoin-payments) for the wider workflow.

## Evaluate settlement reliability

Compare the documented finality signal with the stage the application actually observes. A request acknowledgment, included transaction, finalized block, and provider bank credit are different events.

Tempo's [consensus documentation](https://tempo.xyz/developers/docs/protocol/blockspace/consensus) specifies no re-orgs after a block is finalized and explains the conditions required for network progress. Near-instant onchain settlement is not an unconditional timing guarantee for every funding or payout route.

Test representative payments and failure cases, including an unavailable provider, rejected recipient, expired quote, delayed response, and missed event stream. [Payment lanes](https://tempo.xyz/developers/docs/protocol/blockspace/overview) reserve blockspace for payment activity; they do not guarantee a downstream provider's delivery time.

## Forecast actual payment costs

Tempo network fees are paid in eligible USD-denominated TIP-20 tokens when the fee-token requirements and sufficient Fee AMM liquidity are met. The network uses a bounded dynamic base fee; model the gas used by each operation and its applicable fee rather than assuming one flat fee.

A simple transfer, atomic batch, and contract call can consume different resources. Model the operations your application actually runs. Include custody, funding, conversion, provider charges, local payout, and operational work when evaluating unit economics.

Use [fee-token configuration](https://tempo.xyz/developers/docs/guide/payments/pay-fees-in-any-stablecoin) and [fee sponsorship](https://tempo.xyz/developers/docs/guide/payments/sponsor-user-fees) to define who pays. Monitor the payer's usable balances and handle unavailable fee tokens or depleted sponsorship before they interrupt a run.

## Separate policy primitives from business controls

[TIP-20 Tokens](https://tempo.xyz/developers/docs/protocol/tip20/overview) and the [TIP-403 Policy Registry](https://tempo.xyz/developers/docs/protocol/tip403/overview) supply token-level controls. Account [receive policies](https://tempo.xyz/developers/docs/accounts/policies/receive-policies) can hold receipts instead of delivering them. These primitives do not establish that onboarding, screening, payment approval, or reporting has occurred.

Identify the application, issuer, custodian, and payment provider responsible for each control. Keep authentication, signing permissions, and business approval distinct. Verify the delivered transfers even after transaction success.

If private balances are required, [Zones](https://tempo.xyz/developers/docs/zones) is a separate integration in limited preview. The operator can read the ledger, deposit and withdrawal amounts remain public, and general TIP-20 transfers are disabled in the current runtime. Confirm supported assets, access, and features for the deployment.

## Design reconciliation before scaling

Attach a short opaque [payment reference](https://tempo.xyz/developers/docs/guide/payments/transfer-memos) and keep invoice contents, customer records, and sensitive data offchain. A TIP-20 memo is 32 bytes of public transaction data, not a substitute for the finance database.

Verify the network, token contract, recipient, amount, and delivered events. Store the network, transaction hash, and transfer log index as a unique event key. Update the payment record and invoice together, then retain provider payout evidence for any fiat leg.

Follow historical pagination after interruptions, keep unresolved submissions visible, and inspect existing transaction identifiers before retrying. See [payment reconciliation](https://tempo.xyz/developers/docs/resources/guides/payment-reconciliation) for the AR and AP workflow.

## Establish a production pilot

:::steps
### Fix the scope

Choose one flow, recipient group, asset, and delivery outcome. Record which accounts, providers, custody model, and liquidity balances it needs.

### Define completion and exceptions

Name the evidence that closes each payment and the owner of delayed, blocked, refunded, or unmatched outcomes.

### Measure the complete result

Compare usable recipient funds, total cost, delivery time, prefunded balances, exception rates, and reconciliation work with the existing flow. Expand the parts that meet the operating case.
:::

## Enterprise payment infrastructure questions

### Does a payment gateway replace the settlement network?

No. A gateway can connect checkout, payment instructions, and provider services. The network records the onchain transfer. Establish which component verifies delivery, manages accounts, funds fees, resolves exceptions, and supplies finance records.

### What proves a stablecoin payment reached the recipient?

Verify the successful transaction and expected delivered transfer, including the network, token contract, recipient, and amount. Transaction success alone is insufficient because a receive policy can hold funds. A local-currency bank payout needs separate provider completion evidence.

### What should a provider cost comparison include?

Compare the same funding and recipient outcome using executable quotes. Include network fees, funding, custody, conversion, provider charges, payout fees, and exception-handling work. Record quote expiry and any prefunded balances separately so the comparison captures liquidity as well as payment charges.
