Choose the response you want for requests that match the policy. Approval permits the payment flow to continue; it does not prove that settlement or delivery succeeded.

A request without a matching policy goes to review. Requests to authorize recurring payments also go to review rather than receiving an automatic policy decision.

Spending limits belong to Approve policies. Review and Decline policies apply to matching requests regardless of amount; they are not rules for amounts above a threshold.

Start with a specific purchase pattern. For example, approve MPP purchases from one seller, up to $1 per purchase and $10 per day in USD.

• Payment type selects the kind of request. MPP and x402 are separate policy types. Create a policy for each if you want automatic approval for both.
• Seller limits the policy to a selected seller or applies it to all sellers. Choose the seller account that receives the payment, not merely a matching product name.
• Currency identifies the currency covered by an Approve policy. A USD limit does not also cover USDC or another currency with a similar value.
• Threshold is the maximum amount for one purchase. Set it to 1 for the example’s $1 per-purchase limit.
• Budget and period limit total spending through this policy during each period. Set Budget to 10 and Period to Daily for the example. Once never resets; it provides a total budget rather than a repeating one.
• Expiration sets when the policy stops matching new requests. Leave it blank for no expiration, unless you reserve funds, which requires an expiration.

An Approve policy needs a budget, a threshold, or both. A threshold alone limits each purchase but does not cap their total. A budget alone limits total spending but allows one purchase to use the remaining amount. When both are set, the threshold cannot exceed the budget.

Each policy has its own budget. Separate MPP and x402 policies with $10 budgets do not create one shared $10 limit. Keep an application-wide spending limit separately if your application needs one.

Reserve funds only when needed

Reserved sets aside the full budget from your available balance for that policy. This option is available for a one-time period with a crypto or stablecoin balance, not card payments. Leave it off for the USD example. An ordinary policy controls permission to spend; it does not add funds to your account or guarantee a card charge will succeed.

When a matching approval policy cannot cover a purchase, InFlow declines the request. It does not automatically send that purchase for manual review or try another approval policy with a larger budget.

For the seller-specific MPP policy with a $1 threshold and $10 daily budget, these outcomes assume no competing policy takes precedence:

• A $1 purchase qualifies while at least $1 remains in the budget. An amount equal to the threshold or remaining budget is allowed.
• A $1.01 purchase is declined because it exceeds the per-purchase threshold, even if the full $10 budget remains.
• A $1 purchase is declined when only $0.50 remains. The purchase fits the threshold but exceeds the remaining budget.
• A request from another seller does not match this seller-specific policy. InFlow considers other applicable policies, or sends the request for review if none match.

Budget is consumed when spending is approved, before settlement completes. Do not calculate remaining budget solely from completed purchases. Check the policy’s reported spending and follow the payment’s own status to determine its outcome.

If you want to review every purchase before spending, choose Review. Do not configure a small Approve threshold expecting larger purchases to reach the owner for a decision.

InFlow selects one matching policy. Among policies created by the account owner, Decline takes precedence over Review, then Approve. A seller-specific policy does not automatically override a policy for all sellers.

For example, an MPP Review policy for all sellers takes precedence over an MPP Approve policy for one seller. Purchases from that seller still require review. To approve that seller automatically, remove the overlap rather than adding another approval policy.

Keep one applicable Approve policy for each purchase pattern where possible. Multiple matching Approve policies do not combine budgets, and a seller-specific one is not guaranteed to be selected first.

If the account also has policies authorized through a seller’s policy request, owner-created policies take precedence over those policies. Review the existing policies before adding another rule.

Configure policies in the account your application uses as the buyer. Use Sandbox Policies for Sandbox requests or production Policies for live requests.

Create the example policy

• Select Add Policy. Choose MPP as the policy type and Approve as the action.
• Select USD. Enter a budget of 10 and a threshold of 1, then choose Daily. Leave Reserved off.
• Choose Specific Seller. Search for and select the seller that will receive these payments.
• Set an expiration if you want the policy to stop applying at a particular date and time. Select Save.
• Review the saved policy and any other policies that could match the same purchases before testing.

Change or stop automatic approval

Edit an owner-created policy to change its Enabled setting, expiration, or notifications. Notifications can inform the owner when the policy automatically approves or declines a request; they do not add a manual approval step.

To change the payment type, action, seller, currency, budget, threshold, or period, create a replacement policy. Disable the old policy before using the replacement so overlapping rules do not select an unintended policy.

A disabled or expired policy stops matching new requests. It does not block every purchase: another matching policy can apply, or the request can go to review. Disabling a policy does not cancel an existing payment or refund a completed purchase.

Test the policy decision and your application’s response in Sandbox. Use supported payment paths and controlled purchases alongside your project’s unit and integration tests.

• Make a qualifying purchase. Confirm automatic approval, then check settlement and the seller’s response separately.
• Test an amount exactly at the threshold and another just above it. Confirm that the over-limit request is declined rather than left awaiting review.
• Test a purchase that fits the threshold but exceeds the remaining budget. Confirm that your application reports the decline without creating another payment.
• Test another seller, currency, and payment type. Check whether another policy applies or the request requires review.
• Disable the policy and test expiration separately. Confirm that neither policy remains available to approve new requests.
• Test overlapping Review or Decline policies before relying on automatic approval. Confirm the actual result, not an assumed preference for the more specific seller.
• For a repeating budget, check spending after the period resets. For Once, confirm that there is no periodic budget reset.

Your application must still support manual review and payment failures even when an Approve policy is configured. Follow Approvals and allowances for pending requests and Status and recovery for uncertain outcomes.