A SaaS product can accept USDC in two common ways: publish a reusable payment link for a fixed plan, or create a one-time checkout session from the application backend. The first route is faster. The second gives the merchant a trusted customer ID, a specific order reference and tighter control over redirects and fulfillment.
The payment itself is only one part of the integration. A production flow also needs a way to identify the purchase, detect confirmation, prevent duplicate fulfillment and record what happened.
Payment link or server-created checkout
A payment link works well when the price is fixed and the buyer can reach checkout from a landing page, email, Telegram bot or account settings screen. The link can carry a client_reference_id for reconciliation:
https://app.stendly.com/p/pl_example?client_reference_id=user_8472That value is useful, but it comes from the browser and can be edited. It should not be treated as proof that the payer owns user_8472.
A server-created checkout session is the safer choice when the application already knows the authenticated user. The SaaS backend sends the customer or order reference to the payment API, receives an expiring checkout URL and returns that URL to the browser. The buyer cannot change the price, plan or trusted reference through query parameters.
A minimal production flow
The application creates or selects a product and price. The buyer opens a hosted checkout and pays with a supported stablecoin. After the transaction is confirmed, the payment service sends a signed webhook. The SaaS verifies the signature, checks whether the event has already been processed and activates the plan.
The activation should happen from the webhook handler, not from the success page. A redirect tells the browser where to go after checkout; it does not prove that the payment was confirmed.
A simple database record is enough to make fulfillment repeatable:
provider_event_id
internal_user_id
price_id
payment_status
fulfilled_at
transaction_referenceThe webhook handler should be idempotent. If the same event arrives twice, the second delivery should return a successful response without granting the plan again.
What Stendly handles
Stendly provides reusable payment links, server-created checkout sessions, products, prices, invoices, subscriptions and signed webhooks. A merchant can start with a hosted link and move to the API when the product needs dynamic orders or trusted customer references.
Stendly accepts supported stablecoins including USDC and USDT on Solana and Ethereum. Its wallet and base payment infrastructure use USDC on Solana. During the public beta, Stendly advertises a 0% merchant processing fee; buyer-facing network or third-party costs are shown before confirmation where applicable.
USDC on Solana as a payment rail
USDC is issued on several blockchains. On Solana it is an SPL token, so a transfer uses the Solana fee model rather than Ethereum gas. Solana charges a base fee per signature and can add an optional prioritization fee. The final operational cost can also include creation of an associated token account when the recipient does not yet have one.
Low network cost is useful for small SaaS payments, but token availability matters more than a theoretical fee advantage. If most buyers already hold USDT on TRON, requiring them to bridge or exchange assets can create more friction than the checkout removes. A merchant should test the actual wallet mix of its customers.
Questions to answer before launch
Can a USDC payment be charged back?
A confirmed on-chain transfer does not have the card-network chargeback process. That reduces one type of payment risk, but it also means accidental transfers are not automatically reversible. Refunds need a separate merchant process.
Do users need SOL to pay USDC on Solana?
A standard Solana wallet normally needs SOL for network fees. Some payment systems can sponsor transaction fees or include them in the checkout flow. The exact behavior depends on the wallet and provider.
Can a payment link identify a SaaS user securely?
A public client_reference_id can help reconciliation, but it is not authentication. Use a backend-created checkout session when the user-to-payment binding must be trusted.
Sources
Circle: transfer USDC on Solana