Build the plan to pay an invoice from payer, with the token payer holds (default: the invoice token). Nothing is signed or sent here. Both wallets are screened first (payer_blocked, receiver_blocked); when the invoice has checks ["scorechain"] (see invoice_get), the creator chose and paid the Scorechain sanctions API, so this call sends the payer wallet and the receiver wallet to Scorechain, a third party (an invoice created before 22/10/2026 with the then-free Scorechain keeps running it without a charge). method "transfer": same token, a direct transfer built from the stored invoice (no fee, no gain; the receiver sees the payer as sender). method "swap": another token; amountIn is computed so the GUARANTEED minimum output covers the requested amount, the route is always the one with GAIN when there is one, and the output goes straight to the receiver (the transaction is public and signed by the payer, so the receiver can see the paying wallet on-chain). Any surplus over the requested amount goes to the receiver. plan has the same shape as a swap_build plan: on EVM sign steps[] in order with prepare_signing (approve steps first, then the transaction); on Solana pass {transaction, executionRef} to prepare_signing and POST the signed transaction to /v1/svm/execute. If simulation.status is approval_required, send the approve and call invoice_pay again. When the invoice has paid checks, the creator must have paid the analysis first (analysis_unpaid, 409). With "merkle-science" this call then sends the payer wallet and the receiver wallet to Didit/Merkle Science, and a HIGH or CRITICAL risk (score 70 or more) refuses with payer_blocked or receiver_blocked; the detail shows in invoice_get analysis.report. At most 3 different payer wallets are analysed per invoice by each paid check; a 4th gets analysis_attempts_exceeded (429). Since 23/10/2026 the payer proves the wallet BEFORE the paid analysis runs on it: over MCP that proof is the destination authorization signed by the payer for this invoice's receiver (destination_challenge with wallet = payer, receiver = the invoice receiver, chainId of the invoice, sign the message, then destination_authorize). Without it this call returns payer_signature_required (401) and no analysis slot is spent. Invoices with payerChecks on Solana or enabled EVM networks (see invoice_get payerChecks and split): the paid analysis the receiver chose runs HERE, on the payer wallet, after its free screening passes; it is always on and cannot be switched off. The payer proves the wallet first (destination_challenge/destination_authorize; payer_signature_required 401). At most 2 different payer wallets per invoice (analysis_attempts_exceeded 429); analysis_offer_suspended (403) when the receiving wallet left 2 approved paid analyses without payment. Approved, method "transfer" is ONE payment transaction with the split (on EVM, sign the exact approve step first, then VurtoInvoiceSplit.pay): split.receiverAmount to the receiver and split.fee to the Vurto fee wallet; only that transaction settles the invoice. With another token, method "swap_then_transfer": plan is a swap into the PAYER's own wallet (never straight to the receiver); once it confirms, call invoice_pay again with next.body (tokenIn = the invoice token) and sign the split. If the payer contracted the receiver analysis (invoice_analysis_pay), it must be paid first (receiver_analysis_unpaid 409) and a rejected receiver gets receiver_blocked. Then call invoice_report_payment with the hash (EVM) or signature (Solana). Errors: price_moved (the minimum fell below the request between quote and build — call again), no_route, native_sol_only (an invoice in SOL can only be paid in SOL), invoice_already_paid, private_invoice_paused (a private invoice created before 14/10/2026, paused until the Vurto vault exists). Both wallets are screened before the plan is built: the paying one (payer_blocked) and the receiving one (receiver_blocked). screening_unavailable (503) means the screening could not finish, try again in a few seconds.