What to check before a USDC payment gateway bills your SaaS.

What should a SaaS team check in a USDC payment gateway?

A SaaS team should check how a gateway collects the second payment, not the first. Almost any gateway can take one USDC transfer; far fewer can take the thirteenth without the customer opening their wallet again. Fianto publishes this post, so read our answers in the last column as a vendor's answers, checked against our own docs on 15 October 2026, and put the same questions to anyone else you are considering. The main billing platforms are set side by side in stablecoin subscription billing platforms compared.

The rest of this post takes the rows that need more than a cell. For the product page that sells this to SaaS and API teams, see USDC billing for SaaS, API and RPC plans.

Does the gateway pull renewals, or send an invoice each month?

A gateway either pulls each renewal from the customer's wallet within an approval, or it sends a payment request that the customer has to sign every period. A wallet cannot be charged the way a card can, so the second model is common. Helius, a Solana RPC provider, describes both on its own billing page: renewals are invoiced in USDC on Solana with a payment link by default, an optional "Crypto autopay" charges a connected wallet, and if the wallet is short "There's no automatic retry of the wallet for that invoice", with the project "suspended after 3 days" if the invoice stays unpaid (Helius docs, checked 15 October 2026).

Fianto only does the pull model. The customer signs one transaction at checkout that pays the first period and approves a cap per period, which is the price plus the fees. The Solana Foundation's Subscriptions program then refuses any collection above that cap, to a wallet the plan does not name, or by a collector not on the plan. A monthly plan renews every 30 days and a yearly plan every 365 days; there is nothing in between.

When a renewal fails because the wallet is short, the approval was removed, or the account was frozen or closed, the subscription goes past due and Fianto tries again one hour, six hours and a day after the period boundary. The fourth counted failure ends it, and the missed period is never billed later. Ask any gateway for that schedule in writing: it is your dunning policy whether you chose it or not.

Who holds the money, and who pays the fees?

With Fianto, nobody holds the money: the customer's transaction sends the price to your receiving wallet and, when a fee is due, a second transfer in the same transaction sends it to Fianto. There is no balance and no payout. That also means there is no reserve to negotiate and nothing for us to freeze, and every refund is a transfer you send from your own wallet.

You pay nothing on any charge, including the Solana network fee. Your customer pays these on a 49.00 USDC monthly Pro plan:

For scale, Stripe lists "2.9% + 30¢" per successful domestic US card charge and 0.7% of volume for pay-as-you-go Billing as of 15 October 2026 (Stripe pricing). On a 49.00 plan that is about $2.06 a month from the merchant. The fuller arithmetic, including what cards still do better, is in USDC vs card fees.

How does your backend know a subscription is paid?

Your backend should learn about payments from signed webhooks, not from the success redirect, because a customer can close the tab after signing. Fianto signs every delivery in the Standard Webhooks format, an open specification whose technical steering committee includes people from Zapier, Twilio, Svix and Kong. Any library that implements the spec can verify Fianto's signatures, and the spec tells receivers to "Use the webhook-id header as an idempotency key" (Standard Webhooks spec), which is how you stay safe when the same event arrives twice.

• Subscriptions send subscription.created, subscription.renewed, subscription.payment_failed, subscription.past_due, subscription.cancel_scheduled, subscription.cancel_withdrawn and subscription.ended. A subscription creates no order, so order.paid never fires for one.
• A payment counts at Solana's finalized commitment, not at the first confirmation the customer sees.
• Any 2xx within 10 seconds is a delivery. Otherwise Fianto retries eight times over about 28 hours, and GET /v1/events lists 90 days of events if you need to catch up.
• Every v1 POST needs an Idempotency-Key; a replay within 24 hours returns the first response with Idempotent-Replayed: true; idempotency keys and order ids explains why the order id is the second guard.
• Keys are an app id and a secret sent as Basic auth from your server. There is no publishable browser key, so checkout sessions are always created server-side; the Pay with USDC button walk-through shows that route.

There is no test mode, sandbox or hosted devnet. You test with a signed test.event, the CLI's fianto trigger, or a backend you run yourself, then a small real payment. How to map each event to access is in grant and revoke access from webhooks, and signature checking in the docs under verify webhooks.

What does a SaaS customer need, and how do they cancel?

A SaaS customer needs a Solana wallet that can sign a transaction, USDC on Solana for the price and fees, and a little SOL for the checkout transaction and the rent. The checkout accepts any Wallet Standard wallet that supports signing a transaction, and its list names Phantom, Solflare, Backpack and MetaMask among nine. A team that keeps its funds on an exchange has to withdraw to a wallet first, which is a real drop-off point for business buyers.

Cancelling happens in the customer portal at fianto.xyz/my with one signature, and the plan runs to the end of the paid period. Removing the approval inside the wallet is not a cancel: the next renewal fails, the subscription goes past due, and it ends after the fourth failed attempt. Fianto sends subscribers no emails, so receipts, renewal notices and dunning messages are yours to send from the webhook data.

Where does Fianto fall short for SaaS billing?

Fianto falls short wherever your pricing is more than a fixed amount every 30 or 365 days. These are the gaps a SaaS team hits first:

1. No free trials. The first period is paid inside the subscribe transaction.
2. No usage or seat billing. A subscription charges the same amount every period. Extra usage can be sold up front as a one-off payment.
3. No plan switching or proration. Moving tiers means the customer subscribes to the new plan at checkout and you cancel the old one through the API. Nothing is credited for the unused part of a period.
4. No tax, invoices or fiat. Fianto calculates no tax, issues no invoices and pays out nothing in fiat: USDC lands in your wallet and stays USDC.
5. No team access. One email login per merchant account.
6. USDC on Solana only. No other token, no other chain, no cards.

Approval is also a gate: every merchant is reviewed by a person before the first payment, and no review time is promised. If you need trials, metered usage or card acceptance, a card billing platform is the better choice, and USDC can sit beside it as a second option for the customers who ask. If your plans are flat monthly or yearly tiers for customers who already hold USDC, the walk-through in accept USDC for API and RPC plans shows the build.