Shipping a payment flow on Arc

If you are building a business payment flow on Arc, the work divides into four layers. Most teams underestimate the last one.

1. Getting money in

Your customer holds fiat or holds stablecoins somewhere else. The onramp layer covers minting, exchange withdrawal, and treasury movement into Arc. Since gas is denominated in USDC, funding an operational wallet and funding fees are the same operation — a genuine simplification compared with chains where you maintain a separate gas balance.

Decide early whether you custody or delegate. That choice constrains everything downstream, and it is expensive to reverse after launch.

2. Holding and signing

Wallet and custody is where the compliance conversation actually happens. Options range from institutional custody with policy engines and approval workflows through to embedded wallets your end users never think about.

Ask three questions of any provider: what is the recovery story, what is the approval model for a payment above a threshold, and what happens operationally at three in the morning when a signer is unavailable.

3. Moving and settling

This is the layer teams think of as "the product" and it is usually the least of the work. Payouts, invoicing, cards, and cross-border settlement all reduce to: construct the transfer, get it signed, confirm it, and record it in a form your finance team recognises.

Two things bite here. First, reconciliation: the ledger your accountants use needs a stable identifier for every on-chain movement, decided before launch rather than retrofitted. Second, the last mile — a stablecoin arriving on Arc is not the same as a supplier being paid in their local currency. Local payout coverage is the thinnest part of the stack today and the part most worth prototyping first.

4. Compliance and monitoring

Screening, travel-rule handling, transaction monitoring, and reporting. Providers here plug in at the point of transfer construction and again after settlement. If you are regulated, this layer determines your launch date more than any engineering work will.

Build the audit trail as you build the flow. Reconstructing who approved what, six months later, from block explorer history is a bad afternoon.

Choosing vendors from this directory

Every entry here shows one primary role, a status, and the date we last checked it. Use them like this: live entries are your shortlist, testnet entries are worth a conversation about timelines, announced entries are roadmap signals and nothing more.

Statuses are observations, not endorsements. We do not rate vendors, we record what we saw and when. Do your own diligence on security, solvency and terms — and remember that a "Listing" is a paid submission label, not a statement about a vendor's safety.

A realistic sequence

Prototype the last mile first, because it is the constraint. Then settle custody, because it constrains the rest. Then wire the transfer path, which is the easy part. Then spend the time you saved on reconciliation and monitoring, which is where launches actually slip.