OxaPayBlog: Perspectiva sobre las pasarelas de pago criptográficas

Crypto Payment Readiness Assessment for Businesses

Merchant Readiness Tool

Crypto Payment Readiness Assessment

Check whether your business has enough commercial evidence, clear operational ownership, financial controls, governance, and technical security to run a controlled crypto payment pilot.

24 evidence-based questions 8 readiness dimensions Critical gaps affect the result Runs entirely in your browser
Before you start

Score your current operation—not your future plan

The assessment takes approximately 8–12 minutes. Choose the answer best supported by what exists today. A high total score cannot make up for missing controls in payment exceptions, settlement, legal review, or security. For the full reasoning behind these dimensions, review OxaPay’s crypto payment readiness framework.

Private by design

Your answers remain in this browser. No account, API, or backend is required.

Assessment context

Describe your first use case

These fields help tailor the pilot recommendation. They do not change your readiness score.

Readiness questionnaire

Complete all eight dimensions

0 / 24 questions answered
Dimension 1 of 8 · 10% weight

Customer and Market

Evidence that a specific customer group has a real reason to pay with crypto.

1 Can you identify the specific customer group most likely to pay with crypto?
Evidence: Customer group, country or payment corridor, product, order pattern, and source of demand.

Strong evidence identifies a customer group, market, product, sales channel, or payment corridor instead of relying on general interest in crypto.

2 Do you have consistent evidence of customer demand or payment-access problems?
Evidence: Customer requests, payment declines, checkout abandonment, interviews, or key account requirements.

Examples include repeated customer requests, failed international checkouts, unsupported local payment methods, or requirements from important accounts.

3 Are target customers familiar enough with crypto wallets and networks to complete a payment?
Evidence: Usability tests, customer interviews, expected support needs, and supported wallet options.

You can still proceed if customers need guidance, but you should understand the likely support workload.

Dimension 2 of 8 · 10% weight

Payment Problem and Business Case

A measurable reason to add crypto payments and a clear idea of what the pilot should prove.

1 Can you describe the payment problem in measurable business terms?
Evidence: Current costs, payment declines, settlement delays, disputes, support cases, or conversion rate.

The problem may involve access, cost, settlement delay, chargebacks, failed payments, or customer demand.

2 Have you compared the full business impact, not only the advertised fees?
Evidence: Current payment costs, expected crypto costs, operating assumptions, and excluded costs.

Include integration, support, conversion, refunds, reconciliation, accounting, treasury, and cash-out or off-ramp costs where relevant.

3 Have you defined pilot success measures and when to stop or expand?
Evidence: Pilot KPIs, target values, review date, and the person responsible for the decision.

Useful measures include payment completion, support cases, exceptions, settlement accuracy, cost, and customer demand.

Dimension 3 of 8 · 12% weight

Product, Delivery, and Refunds

Clear fulfillment and refund rules for each product and payment status.

1 Do clear payment and confirmation states determine when an order is fulfilled?
Pilot blockerEvidence: Order-status map, confirmation policy, manual-review rule, and fulfillment owner.

The business should know when to hold, review, fulfill, activate, ship, or reject each order. OxaPay’s guide to payment confirmation systems explains how confirmation evidence should influence fulfillment decisions.

2 Have you defined who handles cancellations and refunds, how refund value is calculated, and who pays the fees?
Pilot blockerEvidence: Refund policy, approval limits, exchange-rate rule, network-fee rule, and customer communication.

The policy should cover the asset and network, exchange-rate timing, network costs, approvals, and customer communication.

3 Do the pilot limits reflect risks specific to your products or services?
Evidence: Eligible products, order cap, fulfillment delay, excluded cases, and approval thresholds.

Instant digital delivery, physical shipping, recurring access, high-value orders, and regulated products create different risks.

Dimension 4 of 8 · 10% weight

Customer Experience and Support

Clear instructions, payment-status updates, investigation steps, and escalation.

1 Do payment instructions clearly explain the amount, asset, network, expiry time, and status?
Evidence: Checkout copy, expiry message, status explanation, fulfillment timing, and error guidance.

Each customer-facing payment option needs clear instructions and a process for handling problems.

2 Is a specific person or team responsible for support and allowed to escalate cases?
Pilot blockerEvidence: Support owner, response target, escalation path, approval limits, and support scripts.

Support should know what it can resolve, what evidence it needs, and when finance, operations, or technical teams must take over.

3 Can the support team investigate a payment using order and transaction records?
Evidence: Order ID, payment ID, transaction hash, asset, network, amount, timestamps, and status.

A useful investigation connects the customer and order with the expected amount, received amount, asset, network, status, and transaction reference.

Dimension 5 of 8 · 16% weight

Operations and Exceptions

Clear ownership, rules for payment problems, order matching, and reconciliation.

1 Is a specific person or team responsible for payment operations?
Pilot blockerEvidence: Primary owner, backup owner, responsibilities, approval limits, and review schedule.

Ownership includes payment review, exceptions, reconciliation, policy changes, and coordination with support and finance.

2 Do you have documented rules for common payment problems and exceptions?
Critical controlEvidence: Owner, evidence source, allowed decision, escalation path, and customer response for each exception.

At minimum, cover underpayment, overpayment, late payment, wrong network, duplicate payment, expiry, and prolonged confirmation. Use the documented OxaPay payment status table to assign each status to an owner and allowed action.

3 Can each payment be matched to an order, reconciled, and protected against duplicate actions?
Pilot blockerEvidence: Order ID mapping, reconciliation report, discrepancy queue, duplicate-prevention (idempotency) rule, and audit trail.

The process should link payment records to orders and prevent repeated events from triggering fulfillment more than once.

Dimension 6 of 8 · 16% weight

Settlement, Treasury, and Finance

Rules for settlement, balance limits, withdrawals, and accounting records.

1 Have you defined which asset to receive, when to convert it, and who owns treasury decisions?
Critical controlEvidence: Target asset, conversion timing, approved provider or route, owner, and exception rule.

Accepting crypto and holding crypto are different decisions. The business should know which asset it wants to receive or hold and who may change that policy. The crypto payment settlement models guide explains the operational differences between settlement approaches.

2 Are balance limits, withdrawal rules, and approval rights documented?
Pilot blockerEvidence: Balance cap, withdrawal schedule, approval roles, allowlisted destinations, and recovery owner.

The policy should cover balances held with the provider, external wallets, withdrawal frequency, approvers, recovery steps, and network fees.

3 Can finance record revenue, fees, refunds, exchange rates, and settlement transfers?
Pilot blockerEvidence: Required data fields, exchange-rate method, ledger mapping, reconciliation report, and record-retention rule.

Readiness requires a repeatable record structure and reconciliation process, even when accounting remains partly manual.

Dimension 7 of 8 · 12% weight

Compliance and Governance

Qualified review, record-keeping duties, and clear policy ownership.

1 Has a qualified reviewer checked the planned model for the relevant jurisdictions and activities?
Critical controlEvidence: Reviewer, scope, jurisdictions, activities, decision record, and open questions.

This assessment does not decide your legal obligations. It checks whether a qualified person owns and reviews them. FATF’s risk-based guidance for virtual assets shows why obligations depend on activity, role, jurisdiction, and risk.

2 Are responsibilities assigned for tax, accounting, reporting, and keeping records?
Pilot blockerEvidence: Responsible people, required records, retention period, reporting calendar, and professional review.

Responsibilities vary by jurisdiction and business activity. A payment gateway does not automatically handle every merchant obligation.

3 Is there a clear process to approve policy changes and review policies regularly?
Evidence: Policy owner, approvers, change history, review schedule, and communication process.

Someone should approve changes to assets, networks, limits, settlement, refunds, access, and launch scope.

Dimension 8 of 8 · 14% weight

Technical and Security

Access control, testing, monitoring, recovery, and safe automation.

1 Are account access, MFA, credentials, and administrator permissions properly controlled?
Critical controlEvidence: MFA, role and permission list, secure credential storage, administrator list, access reviews, and revocation process.

Controls should match the selected implementation method and limit access to payment, API, webhook, withdrawal, and configuration functions. The NIST Cybersecurity Framework 2.0 provides a practical structure for security governance, protection, detection, response, and recovery.

2 Has the chosen integration been tested for all payment states and common failure cases?
Pilot blockerEvidence: Test plan, results, defects, status mapping, rollback steps, and approval for production.

Testing should cover the chosen method, order-status mapping, retries, duplicate events, delayed updates, rollback, and recovery when relevant. Custom API implementations should also be reviewed against the OWASP API Security Top 10.

3 Are responsibilities clear for logging, monitoring, incident response, and recovery?
Pilot blockerEvidence: Logs, alerts, on-call owner, incident checklist, recovery steps, and post-incident review.

The team should be able to detect failed payment updates, suspicious access, reconciliation gaps, and fulfillment mismatches.

Methodology

How the assessment produces your result

Weighted domain scoring

Each question contributes to one readiness area. Operations, treasury, and security carry more weight because failures in these areas can create direct business risk.

Evidence-based answer scores

Answers score 100, 65, 30, or 0 depending on whether the control is tested, partly in place, only planned, or missing.

Critical gaps affect the result

A zero score in exception handling, settlement control, qualified review, or access security produces a Not Ready Yet result, regardless of the total score.

Gap-driven recommendation

The result prioritizes missing owners, policies, evidence, and controls instead of showing only a headline score.

Ready for a Controlled Pilot 78–100

There is no critical gap, every readiness area scores at least 60, and all critical controls are at least partly in place.

Conditionally Ready 55–77

The use case may be valid, but pilot blockers or unclear ownership must be resolved first.

Not Ready Yet 0–54

Missing critical controls, several weak areas, or low overall readiness make a customer-facing pilot premature.

Using the result

The score is a summary; the gaps are the real result

A readiness score is useful only when it improves a launch decision. The most important result is the list of missing owners, rules, controls, and evidence that could turn normal payment activity into operational loss or customer harm.

A business can have strong customer demand and still be unready if settlement ownership, refund rules, exception handling, or access security is missing. It can also have strong controls but a weak commercial use case. The assessment treats both as important findings.

The readiness question is not “Can we receive crypto?” It is “Can we convert a crypto transaction into a controlled business outcome?”

Use the result to define the smallest useful pilot

Limit the first test by customer group, product, transaction value, asset, network, and fulfillment risk. Expand only after measuring demand, support workload, payment exceptions, settlement, and reconciliation.

Read the full readiness framework Review webhook documentation