Quick answer
A crypto billing platform RFP should make vendors prove how money moves, how subscriptions renew, how failed collections recover, and how every on-chain event reaches your ledger. Score custody, recurring authorization, settlement, reconciliation, invoicing, reporting, API reliability, compliance support, and total cost. Require a sandbox demonstration using your billing scenarios before selecting a platform.
What should a crypto billing platform RFP decide?
A crypto billing platform RFP should decide whether a vendor can run your actual revenue cycle safely and economically—not whether it can display a payment address and detect a transfer.
Begin with the operating model. Define who controls funds, which party initiates each recurring charge, what happens when a wallet lacks funds or allowance, and which record becomes authoritative when the blockchain, billing application, and accounting ledger disagree. A one-time checkout can look polished while leaving finance to reconcile monthly subscriptions by hand. That is an expensive demo.
- Billing model: fixed subscriptions, usage charges, invoices, payment links, or a controlled combination.
- Assets and networks: required stablecoins, Bitcoin where relevant, supported chains, and rules for payments sent on the wrong network.
- Custody and settlement: destination wallet, intermediary control, payout timing, conversion dependencies, and access during a vendor outage.
- Revenue operations: retries, cancellations, upgrades, credits, refunds, tax fields, invoice identifiers, and accounting exports.
- Technical control: API coverage, webhook delivery, idempotency, authentication, audit logs, sandbox fidelity, and data portability.
Document the desired crypto billing platform architecture before issuing questions. A self-custodial merchant receiving stablecoins directly needs different controls from a business demanding automatic fiat settlement. Treat that distinction as a gateway requirement, because no amount of scoring can repair a fundamental custody mismatch.
Ask every stakeholder to submit three non-negotiables and one feared failure before the RFP is released. Engineering may fear duplicate webhook processing; finance may fear an unexplained ledger variance; support may fear customers paying from an unsupported chain; legal may fear incomplete transaction records. Convert each concern into a demonstration step with observable evidence. This prevents a familiar procurement trick: assigning equal weight to twenty pleasant features while the one failure capable of stopping revenue receives a single row.
Use a weighted scorecard, not a feature census
Weight the RFP around business failure costs. Custody, collection reliability, reconciliation, and integration usually deserve more influence than cosmetic checkout options.
Score each category from 0 to 5, multiply by its weight, and require evidence for every score above 3. A roadmap promise earns no production-readiness points. Mark genuine deal-breakers separately: a vendor should not win on average after failing a mandatory network, custody, jurisdiction, or recurring-billing requirement.
| Category | Weight | Evidence to request |
|---|---|---|
| Custody and settlement | 20 | Fund-flow diagram; wallet control; outage access; fee path |
| Recurring collections | 20 | Approval model; limits; retries; cancellation; failed-charge states |
| Reconciliation and reporting | 15 | Transaction hash; invoice ID; timestamps; fees; exports |
| API and reliability | 15 | Sandbox test; idempotency; signed webhooks; retries; status history |
| Invoicing and lifecycle | 10 | Plans; usage; proration; credits; refunds; customer records |
| Compliance support | 10 | Screening boundaries; records; geography; data retention |
| Cost and contract | 10 | Platform, network, conversion, support, and exit costs |
The weights are a starting model, not scripture. A platform serving creators may increase cancellation and wallet usability weight; a hosting reseller may emphasize WHMCS events and service suspension; an API company should test whether billing states reliably control request entitlements. Compare the matrix with a broader crypto billing platform buyers guide only after your mandatory requirements are fixed.
Run one subscription through the entire operating sequence
The strongest RFP test follows one subscription from customer approval to month-end reconciliation, including a failed renewal and a refund.
Use explicit assumptions: a SaaS business has 1,000 customers on a $49 monthly plan; 300 choose USDC; 285 renew successfully; 15 fail because of insufficient balance, expired authorization, or another defined state. The vendor must show how approval is captured, when a charge becomes final, which webhook changes access, how retries avoid duplicate debits, and how support identifies the customer from an on-chain transaction.
| Item | Assumption or calculation | RFP evidence |
|---|---|---|
| Scheduled USDC revenue | 300 × $49 = $14,700 | Subscription schedule and invoice population |
| Successful collection | 285 × $49 = $13,965 | Charge states, hashes, timestamps, and customer IDs |
| Platform fee at 0.5% | $13,965 × 0.005 = $69.83 | Separate fee field and wallet movement |
| Uncollected amount | 15 × $49 = $735 | Failure codes, retry state, and customer notice |
Then refund one successful charge and demand a traceable record connecting the outbound transfer, original invoice, reason, approver, and accounting adjustment. Crypto billing refunds are operationally different from card reversals: settlement is final, so the merchant needs a deliberate outbound workflow rather than a chargeback assumption.
Add a duplicate-event drill. Deliver the same successful-payment webhook twice, delay another event, and place a cancellation between scheduling and collection. The vendor should demonstrate stable event identifiers, retry behavior, ordering guidance, and an auditable final subscription state. Also ask what happens if your application acknowledges an event but fails before updating entitlements. This exercise is less glamorous than checkout design, which is precisely why it finds expensive integration defects before customers do.
Where can a winning platform still fail your business?
A high score is insufficient if the platform conflicts with your custody policy, customer wallets, compliance duties, accounting method, or recovery requirements.
Non-custodial settlement removes reliance on a gateway-held balance, but it does not remove merchant responsibility. Your business still needs wallet governance, sanctions and risk controls appropriate to its activities, customer terms, tax treatment, record retention, and lawful refund procedures. A platform can provide useful data or integration points without becoming your compliance department.
- Reject a solution if customers cannot use the assets and networks they actually hold, even when its nominal chain count looks impressive.
- Reject recurring billing that cannot expose authorization limits, cancellation status, failure reasons, and duplicate-safe collection behavior.
- Reject direct settlement if your treasury cannot secure merchant keys, separate roles, approve refunds, and recover operational access.
- Reject reporting that omits invoice IDs, transaction hashes, fees, asset amounts, booking timestamps, or an export path your ledger can consume.
- Reject a contract that obscures network costs, conversion spreads, support charges, data export, termination assistance, or control during service disruption.
Bring finance and legal into the technical demo. Crypto billing compliance and accounting requirements vary by entity, jurisdiction, customer type, and fund flow. The correct question is not whether a vendor is “compliant,” but which party performs each control and which records prove it.
Self-custody is also a poor fit when the business explicitly wants a provider to convert every payment, settle into a bank account, and own most treasury operations. Likewise, smart-contract subscriptions may add unjustified integration work when nearly all revenue is one-off invoicing. Keep cards where customers require them, and consider a mixed payment stack during migration. Procurement should select the architecture that matches the operating burden the team can actually carry, not the one that sounds most independent in a strategy meeting.
How should you select and implement the winner?
Select the vendor through a gated sequence: requirements, written evidence, sandbox proof, finance validation, contract review, limited launch, and reconciliation sign-off.
- Map current plans, invoice rules, wallet destinations, accounting fields, entitlement events, refund approvals, and compliance ownership.
- Issue the weighted matrix with mandatory requirements, scoring anchors, sample payloads, and the worked subscription scenario.
- Shortlist only vendors that answer the fund-flow, recurring authorization, reconciliation, API, and exit questions with verifiable evidence.
- Run sandbox tests for approval, successful renewal, insufficient funds, cancellation, duplicate webhooks, refund, export, and outage recovery.
- Reconcile a limited production cohort from invoice to wallet to ledger before increasing volume or retiring existing payment rails.
- Record ownership for monitoring, customer support, treasury security, contract administration, and periodic vendor review.
For crypto billing for SaaS, the production acceptance test is simple to state: every entitlement change must trace to a valid billing event, and every wallet movement must trace to a customer, invoice, fee, or approved adjustment. Do not call the implementation complete merely because the first payment arrived.
Keep the final decision memo. It should contain the matrix, exceptions, evidence links, residual risks, commercial assumptions, accountable owners, and conditions that would trigger re-evaluation. That document becomes the operating agreement between procurement, engineering, finance, support, and leadership after the sales calls disappear from everyone’s calendar.
Test the RFP against a direct-settlement subscription model
The scorecard should now reveal whether direct wallet settlement and smart-contract subscriptions fit your business. Zyrox supports USDC, USDT, and Bitcoin, with one-time payments, recurring billing, payment links, webhooks, API access, and automatic settlement to the merchant wallet. For recurring USDC subscriptions, customers approve once and subsequent billing runs through smart contracts.
Zyrox is non-custodial, so funds do not wait in a gateway balance, and its platform fee is 0.5%. That makes it a relevant RFP candidate for SaaS, creator, hosting, AI/API, and other global digital businesses that can manage their own wallet, compliance, accounting, and customer obligations. Use the worked scenario as your first acceptance test.
Frequently asked questions
What is a crypto billing platform RFP?
It is a structured request that asks vendors to prove how they support crypto invoicing, recurring collections, custody, settlement, reconciliation, reporting, APIs, compliance boundaries, and commercial terms.
Which requirements should be mandatory?
Make required assets and networks, custody model, recurring authorization, transaction-to-invoice reconciliation, duplicate-safe webhooks, data export, jurisdictional availability, and wallet recovery procedures mandatory where they affect your operating model.
How should vendors be scored?
Use a 0–5 evidence-based scale, multiply each score by a predefined category weight, and apply pass-or-fail gates to requirements that cannot be traded against convenience features.
How do you test recurring crypto billing?
Run approval, successful renewal, insufficient-funds failure, retry, cancellation, duplicate webhook, refund, and reconciliation scenarios using fixed customer and invoice assumptions.
Does non-custodial billing eliminate compliance obligations?
No. Direct wallet settlement changes custody exposure, but merchants remain responsible for applicable sanctions controls, taxes, customer terms, recordkeeping, wallet governance, and other legal duties.
Should an RFP require invoicing and accounting exports?
Yes. Require invoice and customer identifiers, asset and booking amounts, transaction hashes, timestamps, fees, refunds, and an export or API path compatible with the accounting process.
When is a non-custodial platform the wrong choice?
It may be unsuitable when the business wants mandatory fiat settlement, outsourced treasury custody, or minimal internal wallet responsibility, or when its revenue is almost entirely one-off invoicing.
How many vendors should reach the sandbox stage?
Advance only vendors that pass mandatory requirements and provide credible written evidence. The appropriate number depends on procurement capacity; each finalist should complete the identical operating scenario.