Suppose a seller offers a report for $1.00 USD through an instrument payment. Your application selects that offer and requests payment using the buyer’s saved card. After approval, InFlow processes the card charge through Stripe for the connected seller. Confirm payment completion before treating the purchase as paid.

This charges the card for the purchase; it does not add $1.00 to the buyer’s InFlow balance first. The seller receives the card payment through their connected Stripe account, rather than as an InFlow balance transfer.

A saved card is available only to the InFlow account that owns it. Linking a card does not authorize every purchase or make every seller accept that card. The seller must offer a compatible payment option, and the charge can still require authentication or be declined.

Sign in to the buyer account your application uses. Open Sandbox Instruments for testing or production Instruments for live purchases. Cards and account credentials belong to the selected environment.

• Select Add Instrument and enter a name that helps you recognize the card.
• Enter the card number, expiration, and security code in the hosted card fields. Provide the billing postcode where applicable.
• Select Save. Confirm that the card appears in Instruments, with the expected last four digits and Enabled status.
• Check which card is marked Primary. Use Make Primary on another enabled card to change the default.

A newly linked card becomes primary when the account has no primary instrument. Adding another card does not replace an existing primary card. An instrument payment uses the primary card unless the request explicitly selects another instrument owned by the buyer.

Keep card entry in the dashboard’s hosted fields. Your payment integration uses the saved instrument reference, not a card number or security code. Do not put raw card details in application configuration, payment examples, logs, or source control.

The seller needs an InFlow Seller account with Stripe connected in the same environment as the integration. Open Sandbox Stripe settings or production Stripe settings to connect the account and check payment readiness.

Complete any outstanding Stripe requirements and confirm that the connected account can accept payments. Connecting the account and being ready to receive charges are different conditions. The buyer does not need to connect a merchant Stripe account to save a card.

Advertise an instrument payment option with a USD price of at least $0.50, in whole cents. For example, $1.00 USD is valid; $0.01 USD is below the minimum. Use $1.00 for the test purchase rather than copying the 0.01 USDC price from the balance-payment examples.

A connected account alone does not add instrument offers to your endpoints. Configure the seller integration to offer the instrument option explicitly. See Prices and offers for price and payment-option configuration.

Select an instrument offer from the seller’s advertised payment requirements. The protocol determines how that option is named:

For MPP, check the rail as well as the method: the inflow method also supports balance payments. For x402, select the instrument scheme rather than a balance or blockchain payment. Follow Choose payment options when several offers are available.

Other card payment options

MPP’s stripe method accepts a Stripe Shared Payment Token. That token is a different credential from an InFlow-linked instrument. A buyer with a saved InFlow card cannot assume the card can pay an offer that only accepts the Stripe method.

Visa CARD is also a separate MPP payment path, with its own credential and allowance requirements. You do not need to create a Visa CARD allowance merely to make the instrument payments described here. The Visa CARD guide covers that separate setup.

InFlow approval gives permission to make the purchase. The card issuer can separately require the cardholder to authenticate the charge. Neither decision alone proves that payment has settled.

• Select the seller’s instrument offer and the intended card, then request payment through your buyer integration.
• Complete any required InFlow approval. Keep the transaction reference while the owner reviews the request.
• Submit the prepared payment credential to the seller. Check the resulting payment status rather than assuming approval guarantees success.
• If the transaction reports nextAction.type as authenticate_card, direct the owner to the supplied nextAction.url address. The owner signs in to InFlow and completes the card verification there.
• Read the same transaction again after verification. Confirm the payment outcome and delivery of the purchased result before marking the purchase complete.

Use the supplied InFlow verification URL without adding your API key or other credentials. Keep the existing transaction when authentication or processing is pending. Starting another purchase can create a second charge instead of completing the first.

See Approvals and allowances for the owner’s approval flow. Status and recovery explains card verification and recovery after an interrupted response.

Use Sandbox buyer and seller accounts with the corresponding test card and processor setup. Selecting Sandbox in an SDK does not make a production card charge a test. Start with a $1.00 USD instrument purchase and run these cases alongside your application’s tests:

• Complete a successful purchase. Confirm the InFlow transaction, the payment in the seller’s Stripe account, and delivery of the purchased result.
• Test a card decline. Confirm that your application reports the failure without changing cards or creating another purchase automatically.
• Test a payment that requires card authentication. Complete the supplied verification flow and check the original transaction afterward.
• Test a missing, disabled, or expired selected instrument. Confirm that the failure does not silently charge another saved card.
• Test primary-card selection and an explicit card selection separately if your application supports both.
• Interrupt a response after submitting payment. Recover using the existing transaction rather than treating a timeout as a failed charge.

Maintain saved cards

Review saved cards in Instruments when a card expires or the owner wants to change payment preferences. Use Make Primary to change the default. To disable a primary card, first make another enabled card primary. Use the available Edit, Disable, Enable, and Delete controls as appropriate.

Changing the primary card does not replace the card already selected for an existing transaction. Removing or disabling a card is not a refund or a cancellation of a submitted charge. Check the transaction’s outcome separately and avoid changing card setup while investigating an uncertain payment.