P2Flux for WooCommerce

Straight to the wallet you configure, in the same transaction the customer sends. P2Flux never holds it and cannot move it.

Nothing is lost. The order keeps its payment instruction, the plugin checks whether the payment arrived, and the customer's own "I already paid - check my payment" link asks the same question. It never offers to pay again while a payment might already exist.

Yes, in full, from your own wallet. The order screen has a P2Flux box that prepares the refund and opens your wallet; WooCommerce records the refund once P2Flux confirms the transfer on chain. The refund on chain is the USDC the customer paid; the WooCommerce refund record is the order total in your store currency, so on a non-USD store the two figures differ by the conversion applied at checkout (recurring products are USD-only, so the two always agree there). WooCommerce's normal refund button is not offered, because no server can send money out of your wallet - only you can. The P2Flux protocol allows exactly one refund per payment, so the plugin offers that refund in full: a partial refund would use up the only refund the order will ever have.

They choose P2Flux, place the order, and a small P2Flux window opens from that same click: connect a wallet, confirm, done. The order's pay screen stays behind it to show progress, and if a browser refuses the window it offers a button that opens it on demand - "Pay with USDC — no ETH required" when the network fee is paid in USDC.

Not with "No-ETH checkout" on (the default for new installs). The customer pays the price plus the network fee in USDC, signs once in their wallet, and P2Flux sends the transaction: their wallet needs USDC on Base and no ETH at all. The exact network fee is shown in the P2Flux window before they confirm. A customer who holds ETH on Base can choose "I have ETH on Base — pay the network fee in ETH" on the pay screen instead. The setting costs you an extra fixed 0.10 USDC per payment made that way (see Fees), and it does not apply to subscriptions. Stores upgraded from 1.0.0 keep it off until you turn it on under WooCommerce → Settings → Payments → P2Flux.

It is safe for a customer to close the browser after confirming a payment. The payment instruction is stored on the order, so the store can find the payment on the blockchain without the customer:

• Automatic checks run about 15 minutes, 1 hour, 6 hours, 24 hours and 48 hours after the payment was started. A payment found is verified and marks the order paid with its exact transaction.
• A daily sweep re-queues those checks for P2Flux orders from the last week that are still pending.
• A customer who comes back to the order's payment page is checked first, before being offered to pay, and "I already paid — check my payment" asks at once.

It depends on why, and the plugin says so on the order. A wallet that is short of USDC is retried daily for three days and the customer is told to top up. An approval that ran short cannot be fixed by retrying, so the customer gets a "Restore USDC approval" button on their account page. A customer who revoked their authorization has their subscription cancelled.

Renewals stop, with a note on the order, because the customer's wallet authorized the old amount and the plugin never charges an old authorization for new terms. The customer's account page explains the new amount and offers "Re-authorize": one signature in their wallet, and the outstanding renewal is collected straight away. The old authorization stays on record so its payments remain refundable.

WooCommerce stops collecting immediately - that part is entirely in the store's hands. The standing permission in the customer's wallet is theirs to remove, and their account page offers it.

Not in this version. A subscription's first charge and its renewals are one signed amount with one start date, so a trial would need protocol support that does not exist yet. Sign-up fees, a second subscription, or anything else in the cart alongside the subscription - all of which make the first payment differ from the renewals - are unsupported for the same reason. P2Flux is simply not offered for such a cart, rather than selling a subscription it cannot renew; the customer pays with another method, or removes the extra item.

Because the subscription has no end and the approval can only ever be used for the terms the customer signed: it is granted to the P2Flux recurring contract, which moves nothing a signed authorization does not permit. If you would rather bound it, the "USDC approval for subscriptions" setting asks the wallet for 12, 24 or 36 billing periods' worth instead; when that runs out the customer's account page offers "Restore USDC approval" and the renewal is collected right after.

Not in this version. A recurring authorization fixes one USDC amount for its whole life, so a subscription priced in another currency would drift away from its own price as the rate moved - and neither you nor the customer would have agreed to what it became. One-time payments convert normally.

Not for simple fixed subscriptions. P2Flux Native Subscriptions handle a fixed price, one product, one interval, with renewals, dunning, cancellation and refunds. WooCommerce Subscriptions is still the right choice for free trials, sign-up fees, variable subscriptions, switching and proration, which native mode intentionally does not do. Feature comparison - P2Flux Native / WooCommerce Subscriptions: simple fixed subscription yes/yes; USDC recurring yes/via P2Flux; free trial no/WCS may support; sign-up fee no/WCS may support; variable subscriptions no/WCS may support; switching and proration no/WCS may support; multiple advanced lifecycle features no/yes.

The customer authorizes it in their wallet at checkout and the first payment is collected right away. The first payment must complete shortly after authorization; if the setup expires before it does, the subscription is marked expired, it never activates, and nothing is charged automatically later. The customer simply starts a new order. An expired signup keeps its unused wallet authorization on record so the customer can revoke it from My Account.

The renewal order is marked failed, the subscription goes on hold, and the customer is emailed what to do (add USDC, restore the approval, or authorize again). Retries stay inside the renewal's own billing period. A period that passes unpaid is never collected later, there is no catch-up billing, and the subscription is not cancelled automatically however many renewals are missed: it stays on hold until a later payment succeeds or somebody cancels it. If the store was offline for a while, at most one payment is attempted when it comes back - the current one.

Encrypted, in your own database, and never in a log, a page or a URL. For stronger protection add a key to wp-config.php: define( 'P2FLUX_WC_ENCRYPTION_KEY', 'your-base64-key' ); Without it the plugin generates a key and stores it in the options table, which protects an exported orders table or a stolen backup but not a full database compromise. To rotate: set the new key, keep the old one in P2FLUX_WC_ENCRYPTION_KEY_PREVIOUS, and every stored authorization keeps working while new ones use the new key.