The Product
Intent In, Fiat Out - The Full Flow
Complete payment lifecycle from intent to fiat delivery.
Updated Feb 23, 2026
This is the complete journey a payment takes through Papillae from the moment an instruction arrives to the moment fiat lands in a recipient's account.
1. Intent arrives
The instruction comes in. It can be natural language from a user or AI agent - "send $300 to my mom in Manila" - or a structured API call from a developer system. If it is natural language, the intent parser extracts the structured data: amount, currency, recipient, corridor, urgency. If it is already structured, the engine receives it directly.
Either way, the engine receives a clean payment object with all the fields it needs.
2. Compliance gate
Before anything else happens, the compliance engine runs. It checks the sender against the sanctions database. It checks the recipient address or name against the same. It checks whether the corridor is active and within transfer limits. It checks whether travel rule requirements apply to this amount.
If anything fails here, execution stops immediately. The funds have not moved. The user gets a clear explanation of why.
3. Route planning
The routing engine evaluates every available path. For a US to Philippines transfer, it might evaluate direct USDC bridging via CCTP versus swapping to a different stablecoin first versus routing through an intermediate chain. It scores each path against live data - current fees, current bridge latency, last hour success rate per protocol, off-ramp partner availability.
It selects the primary route and pre-computes two fallback routes. If the primary fails mid-execution, the engine does not start from scratch. It already knows what to do next.
4. Pre-flight simulation
The engine calls simulate() on the smart contract. The entire route executes as a dry run. No funds move. Liquidity is checked at the actual transfer amount, not a sample amount. Slippage is estimated against real pool depth. The off-ramp partner API is pinged for availability. Expected output is calculated.
If expected output is below the user's minimum, execution does not begin. The engine returns the simulation result and waits for instruction.
5. Execution
The user's funds are pulled from their wallet into the Papillae vault contract under a unique payment ID. From this point the funds are locked in an isolated on-chain escrow until they are either delivered or returned.
The engine executes each hop in sequence. If the route includes a swap, the swap adapter calls the relevant DEX. If the route includes a bridge, the bridge adapter calls the relevant bridge protocol. The funds move through the Papillae smart contract - external observers see one interaction with the Papillae contract, not a trail across Uniswap and Across and Stargate.
6. Off-ramp delivery
When the funds arrive on the destination chain, the off-ramp partner - Yellow Card, Coins.ph, Bitso - receives USDC into their wallet. They have local currency pre-funded in their treasury. They pay out instantly from that treasury, converting to Philippine pesos, Nigerian naira, or Mexican pesos at the agreed rate.
The recipient gets fiat in their bank account or mobile wallet. They never needed a crypto wallet. They never needed to know this happened on a blockchain.
7. Settlement confirmation and webhook
The engine monitors for confirmation of local currency delivery. When confirmed, it fires a webhook to whatever system initiated the payment. The webhook includes the payment ID, final amount delivered, actual fee, actual time taken, and a link to the compliance proof bundle.
The transfer is complete.