This is the honest version of a post the SEO title wants to be.
Settlematic’s Solana deposit program uses PDAs: findProgramAddress([b"deposit", sha256(entityId||destination)]), with sweep_native / sweep_token in the program. The production payment path we actually run for invoices is native SOL, not USDC-on-Solana. If you need USDC, use Ethereum / Polygon / BSC (and the other EVM paths we support). Do not send USDC-SPL to a SOL invoice address and expect a green check.
Why people want USDC on Solana
Fees and speed. Completely reasonable. Shipping it as a production invoicing asset means token accounts, ATA creation, mint pinning, and recovery when someone sends the wrong mint. We have not wired that as a live Collect settlement asset. Marketing pages that imply otherwise are ahead of the payment path.
If you still want Solana
Quote fiat, bind a PDA, payer sends SOL, indexer waits for finality, webhook fires. Same uniqueness rule as EVM: do not reuse one PDA across invoices.
If a competitor actually settles USDC-SPL in production, ask them for the mint, the ATA policy, and a sample tx. Then ask who can sweep.
Canonical: accept Solana USDC invoices — read it as the product essay, and treat this Dev.to post as the constraint. settlematic.com
Top comments (0)