A payment approval records InFlow’s decision about a particular spending request. The account owner can review the request, or an applicable policy can make the decision. A fresh manual approval is not required for every purchase.

• Payment approval concerns the purchase being requested. The owner can approve or decline it in InFlow.
• Account policies are saved rules for approving, declining, or sending requests for review. Their configuration belongs in Policies.
• Card allowances authorize supported Visa Intelligent Commerce card spending within an amount and expiration chosen by the owner. InFlow payment approvals and policies still apply.

These controls do not replace your application’s purchase rules. For example, an account policy may permit spending more than your application’s limit for a report. Check the seller’s offer before requesting payment, as described in Choose payment options.

Approval permits the payment flow to continue. It does not prove that settlement succeeded or that the seller delivered the purchased result.

Keep one payment attempt while the owner decides. Retain its transaction and approval identifiers when your integration exposes them. They identify the existing request; they are not payment credentials or proof of payment.

Tell the owner what needs attention

Show the purchase, seller, amount, and currency your application is requesting. When approval is pending, tell the owner to open Approvals in the buyer’s InFlow account and review that request. The account and environment must match those used by your application.

Use Sandbox Approvals for Sandbox requests and production Approvals for live requests. The owner logs in to InFlow; your application does not need to collect the owner’s dashboard password or verification codes.

Choose how your application waits

Automatic payment helpers can wait for InFlow to produce a credential before retrying the seller request. An application that needs to display the approval reference can use an explicit preparation flow where its SDK supports one. Preparation creates the request; the subsequent wait follows that request until a payment credential is available or the operation fails.

The SDKs do not expose identical progress callbacks or preparation methods. Use the flow documented for your language in Pay with MPP or Pay with x402. A pending payment can also be waiting on processing, so do not label every pending result as requiring a new owner decision.

Give the owner time to respond without freezing your interface. If your application manages polling directly, follow the returned retry interval where provided and set a bounded waiting time. Do not submit another payment request each time you check progress.

Continue from the payment result returned by InFlow, not from a message that the owner clicked Approve. Credential preparation can still be pending or fail after approval.

Keep the approved purchase intact. Changing its price, recipient, or requested product is not continuation of the same purchase. If the seller’s terms expire while the owner is deciding, stop and reassess the purchase rather than altering the credential.

InFlow’s Visa Intelligent Commerce (VIC) flow uses a card allowance for MPP card payments. The owner authorizes spending across merchants using that card, up to the chosen amount and expiration. This allowance is not required for ordinary InFlow balance payments or every payment funded by a linked card.

Complete allowance setup before starting a CARD purchase. InFlow checks that the selected card is usable and has a verified, unexpired USD allowance with enough available capacity. A card without that allowance can be rejected before a purchase approval is created.

• Open Instruments in the buyer’s InFlow dashboard and choose the supported Visa card. Open its VIC Allowance controls.
• Select Create Allowance. Enter the permitted USD amount, a future expiration in the displayed account timezone, and a description of the permitted spending.
• If the allowance shows Awaiting Visa verification, select Complete Verification and follow the secure verification window. Creating or verifying the allowance does not charge the card.
• Confirm that the allowance is Ready and has enough available capacity before starting the purchase. The selected card must be the card whose allowance you prepared.

An allowance authorizes card spending; it is not a prepaid balance. Issued payment credentials consume allowance capacity even before payment. Do not calculate remaining capacity solely from completed purchases. Check the dashboard’s reported available amount and refresh its status when needed.

If setup is unconfirmed, use Check Status before starting another allowance request. An expired, cancelled, or unverified allowance is not ready for a new CARD purchase. See Visa CARD for the payment integration and Linked cards for card setup.

Tell the buyer whether your application stopped waiting or confirmed that the request was cancelled. These are different outcomes. A disconnected browser, cancelled task, or local timeout does not establish what happened on the server.

Use your SDK’s cancellation operation when abandoning an unfinished purchase. Some SDK flows also try to cancel pending approval when waiting fails. Cancellation and timeout behavior differ by SDK and flow; do not assume you can resume every prepared payment after a timeout.

A cancellation request can fail or arrive after approval has already completed. It does not reverse settlement. Before starting another purchase, check the existing transaction when its outcome is uncertain. Status and recovery covers those checks.

Cancelling a card allowance is a separate action. It stops InFlow from selecting that allowance for new credentials, but does not refund payments or guarantee cancellation of credentials already issued. Leaving the Visa verification window also does not cancel the allowance.

Test both the buyer’s experience and the requests your application sends. Use controlled Sandbox purchases for supported payment paths, alongside your project’s unit and integration tests. A successful approval alone is not a completed payment test.

• Approve a pending request. Confirm that the application continues the existing attempt, submits the ready credential, and checks the seller’s result.
• Decline a request and test expiration separately. Confirm that neither outcome triggers another payment request or a fallback to another payment method.
• Test a purchase permitted by an account policy. Confirm that the application can proceed without waiting for a manual click that is not required.
• Interrupt waiting before and after the owner responds. Confirm that the application distinguishes a known cancellation from an unresolved payment.
• For CARD integration, test a ready allowance and missing, expired, unverified, or insufficient allowance capacity. Confirm clear failure messages and no repeated purchase creation.
• Confirm that passwords, verification codes, and payment credentials stay out of application logs and progress messages.

Simulated failures help exercise expiration and interrupted requests, but do not establish real card-provider support. Check the selected payment path’s test-environment requirements before claiming an end-to-end result. See Test your integration for the broader test plan.