How long does onboarding actually take?

Plan for 2-4 weeks minimum, even for sandbox access. Their compliance team moves slower than they advertise. If you're in a "high-risk" industry (crypto, gaming, adult content), add another month. Unlike Stripe's instant sandbox access, you'll be waiting.

Why does Apple Pay integration suck compared to Stripe?

Because they make you handle all the Apple Pay bullshit manually. Token exchanges, eligibility checks, payment sheet garbage - Stripe just does this for you. Budget 3x the development time you'd spend on Stripe's Apple Pay implementation.

Do their "competitive rates" actually save money?

Maybe, if you process massive volume and negotiate hard. For most businesses under $1M monthly processing, the rates are similar to Stripe after accounting for hidden fees. The real savings come at enterprise scale ($10M+ monthly) where they'll actually compete on pricing.

What breaks when you hit production scale?

The fraud detection goes haywire first. Expect legitimate transactions to get flagged while obvious fraud slips through initially. You'll spend weeks tuning rules and thresholds. Their routing optimization also needs manual adjustment - it doesn't "learn" your patterns like they claim.

How's their support when shit hits the fan?

Depends entirely on your contract tier. Basic support is slow (24-48 hours). Enterprise gets decent response times, but you'll often get bounced between L1 and L2 before reaching someone who understands the technical issue. During outages, communication is poor compared to Stripe's status page updates.

Can you actually migrate from Stripe easily?

The API patterns are similar enough that migration is possible, but expect integration differences around webhooks, error handling, and payment flow states. Budget 2-3 sprints for a clean migration, not the "drop-in replacement" their sales team implies.

What's the biggest gotcha they don't mention?

Settlement timing varies by region and payment method in ways that aren't well documented. What works in the UK might have different timing in Germany or Singapore. Test thoroughly in each target market before launch.

Is their dashboard actually usable?

It's functional but dated compared to Stripe's sleek interface. Reporting is adequate for basic needs, but you'll likely build custom dashboards for anything sophisticated. The search and filtering capabilities are particularly weak.

What happens if you get flagged by their risk system?

Account holds can happen with minimal warning, especially for newer merchants. Their risk review process is opaque and slow. Unlike Stripe's relatively transparent approach, you'll often be left guessing what triggered the flag.

Should startups use Checkout.com?

Probably not. Unless you have specific geographic requirements (Middle East, certain Asian markets) that Stripe doesn't serve well, the additional complexity isn't worth it for early-stage companies. Stick with Stripe until you have clear evidence of better economics at scale.

Why do I keep getting "request_json_invalid" errors?

This is their shitty way of saying your JSON is fucked up. Unlike Stripe, which tells you exactly what's wrong, you get to play detective. Nine times out of ten it's because you forgot amounts need to be in cents (not dollars) or used the wrong currency code. Common culprits: currency codes (use ISO 4217), amount formatting (integers in smallest currency unit), and date formats (ISO 8601 required). Check their [official error codes](https://www.checkout.com/docs/developer-resources/codes/error-codes) for the complete list.

How do I handle their webhook signature verification?

Their webhook signing is different from Stripe's approach. You need to verify the `Cko-Signature` header using HMAC-SHA256. Here's the gotcha: they don't include timestamps in signatures like Stripe does. So if someone captures your webhook payloads, they can replay them later. You get to implement your own replay protection because apparently that's too much to ask from a payment processor. **The webhook verification process works like this**: Checkout.com sends a request with the `Cko-Signature` header containing an HMAC-SHA256 hash of the payload using your webhook secret. You recreate the hash on your end and compare. Unlike Stripe's approach that includes timestamps to prevent replay attacks, you need to implement your own replay protection. Pro tip: Never update their SDK on Fridays. Their webhook signature validation broke for 6 hours on March 15th, 2024, with zero communication until developers started complaining on Twitter. **Pro debugging tip**: If webhook verification suddenly fails, check for trailing whitespace in your secret key. Their dashboard sometimes adds invisible characters when you copy the key. Took us four hours to figure that out.

Why does 3D Secure authentication keep failing?

Their 3D Secure implementation requires specific browser handling that's not well documented. You need to handle the authentication redirect flow manually and ensure your frontend properly handles the challenge responses. Unlike Stripe's seamless handling, you're managing more of the authentication state yourself.

What's the deal with their "source" vs "destination" terminology?

This confuses everyone coming from other processors. In Checkout.com's API: - **Source**: Where money comes from (customer payment method) - **Destination**: Where money goes to (your account, marketplace split, etc.) It's different from Stripe's simpler charge model and requires rethinking your payment flow logic.

How do I test different payment methods in sandbox?

Their sandbox test cards are buried in documentation and don't cover all scenarios. For Apple Pay testing, you need actual iOS devices with test Apple IDs - their simulator support is limited. Google Pay testing is similarly constrained. Budget extra time for payment method testing.

Why are my recurring payments failing randomly?

Checkout.com's recurring billing isn't as robust as Stripe's. Failed recurring payments often need manual retry logic because their automatic retry attempts are limited. Also, their "dunning management" is basic - you'll likely need to build your own retry schedules and customer communication.

How do I handle currency conversion properly?

Unlike Stripe's transparent FX handling, Checkout.com requires you to be explicit about multi-currency processing. You need to specify whether you want DCC (Dynamic Currency Conversion) and handle the customer currency selection flow yourself. Their FX rates update frequency isn't clearly documented.

What's the real latency for authorization responses?

Despite claims of "real-time" processing, authorization responses typically take 300-800ms in production. This is slower than Stripe (100-300ms average) but faster than some traditional processors. Plan your UI accordingly - don't assume instant responses.

How do I debug failed transactions?

Their error codes are less descriptive than Stripe's. You might get `card_authorization_failed` which could mean anything from "insufficient funds" to "card blocked by issuer" to "we just don't like this transaction." Pro tip: check the `response_code` field - if it's "20051" the customer's card is probably fine, but their fraud system flagged it. If it's "20014", the card is actually declined. Keep their [error code documentation](https://www.checkout.com/docs/developer-resources/codes/error-codes) bookmarked.

Why does settlement take longer than advertised?

Settlement timing varies by: - Payment method (cards vs bank transfers) - Issuing bank location - Your merchant category code - Transaction amount thresholds Their "T+1" claims often become "T+2 or T+3" in reality, especially for international transactions. This affects cash flow planning more than they admit.

How do I handle marketplace payments and splits?

Their marketplace functionality exists but isn't as polished as Stripe Connect. You'll need to: - Manage sub-merchant onboarding manually - Handle split payment calculations yourself - Deal with separate compliance requirements per sub-merchant The documentation assumes you understand payment facilitator regulations, which most developers don't.

What happens when their API goes down?

Unlike Stripe's graceful degradation, Checkout.com's API tends to fail harder during outages. Their rate limiting is also less predictable - you might get rate limited without clear indication of when to retry. Implement circuit breaker patterns and robust retry logic with exponential backoff. We processed $12K in duplicate charges during a webhook retry storm when their validation endpoint went down. Their "99.9% uptime" claims don't account for these partial failures that still fuck up your business.

What are the limitations of their dashboard?

Their dashboard search is garbage - try searching for transactions by amount. Spoiler: you can't. Date ranges randomly break if you go past 90 days, and CSV exports timeout if you have more than like 1000 records. **Dashboard limitations you'll hit**: Search only works on transaction IDs and customer emails, not amounts or metadata. Date range picker breaks if you select more than 90 days. CSV exports timeout on anything over 1000 records. The pagination is slow and clunky compared to Stripe's smooth infinite scroll.

Currently viewing the AI version

Switch to human version

Checkout.com Payment Processor: Technical Integration Guide

Configuration Requirements

Onboarding Timeline

Sandbox Access: 2-4 weeks minimum (vs Stripe's instant access)
High-Risk Industries: Add 1+ month (crypto, gaming, adult content)
Production Approval: Additional 1-2 weeks for compliance review

Critical Settings

Amount Format: Must use smallest currency unit (cents, not dollars)
Currency Codes: ISO 4217 format required
Date Formats: ISO 8601 required
Webhook Secret: Check for trailing whitespace (common dashboard bug)

Resource Requirements

Development Time Estimates

Basic Integration: 3x longer than Stripe equivalent
Apple Pay Integration: 3-5 days (vs 30 minutes with Stripe)
Migration from Stripe: 2-3 engineering sprints
3D Secure Implementation: Manual redirect flow management required

Volume Thresholds for Economic Viability

$3M+ monthly: Negotiating leverage begins
$5M+ monthly: Custom pricing available (20-30 basis points savings)
Under $1M monthly: Rates similar to Stripe after hidden fees

Hidden Cost Factors

Cross-border fees (not disclosed upfront)
Currency conversion margins
Assessment fees on enterprise contracts
Higher rates for Amex/corporate cards
Engineering overhead: $30K reported for 6-month period

Critical Warnings

Production Failure Modes

Webhook Signature Validation: No replay protection (unlike Stripe)
API Outages: Fail harder than Stripe's graceful degradation
Settlement Delays: T+1 claims often become T+2 or T+3
Fraud Detection: Overly aggressive initially, requires tuning
Rate Limiting: Less predictable than competitors

Breaking Changes Without Notice

iOS SDK 3.2.0 → 3.2.1: Changed error handling, caused production failures
March 15, 2024: 6-hour webhook signature validation outage
SDK updates on Fridays caused weekend debugging sessions

Geographic Limitations

Settlement timing varies significantly by region
Different payment method availability by market
Local acquiring needed for optimal authorization rates in APAC

Technical Specifications

API Performance

Authorization Response Time: 300-800ms (vs Stripe's 100-300ms)
Webhook Reliability: Good when working, difficult debugging
Rate Limiting: Unpredictable thresholds
Uptime Claims: 99.9% doesn't account for partial failures

Payment Method Support

Region	Advantage Over Stripe	Specific Methods
APAC	Deeper local coverage	GrabPay, Touch 'n Go eWallet, local bank transfers
Europe	Better 3DS 2.0 implementation	SEPA, iDEAL, improved SCA compliance
Global	150+ currencies vs Stripe's subset	More exotic currency options

Integration Complexity

3D Secure: Manual redirect flow management required
Apple Pay: Token exchanges, eligibility checks, payment sheet handling
Webhook Verification: HMAC-SHA256 with Cko-Signature header
Multi-Currency: Explicit DCC handling required

Decision Framework

Choose Checkout.com When:

Processing $3M+ monthly with negotiating leverage
Significant APAC/MENA market exposure requiring local payment methods
Complex risk profile needing custom tuning capabilities
Advanced SCA compliance features required for EU markets
FX optimization provides measurable cost savings

Avoid When:

Under $1M monthly processing volume
Primarily US/basic international markets
Developer velocity prioritized over cost optimization
Limited engineering resources for integration complexity

Competitive Positioning

Stripe: Superior developer experience, higher cost at scale
Adyen: Enterprise-grade but requires $50M+ volume and technical resources
Checkout.com: Middle ground - more complex than Stripe, less capable than Adyen

Common Implementation Issues

Error Handling

request_json_invalid: Usually amount formatting or currency code errors
card_authorization_failed: Generic error requiring response_code analysis
Response code "20051": Fraud system flag (card likely valid)
Response code "20014": Actual card decline

Dashboard Limitations

Search only works on transaction IDs and emails, not amounts
Date range picker breaks beyond 90 days
CSV exports timeout over 1000 records
No amount-based transaction filtering

Webhook Debugging

Inconsistent retry cycles (unlike Stripe's reliable 3-day cycle)
No timestamp inclusion in signatures
Signature validation can break during SDK updates
Replay attack protection must be implemented separately

Migration Considerations

From Stripe

Cannot simply swap API keys
Different webhook structures and error handling patterns
Settlement timing changes affect cash flow
Keep Stripe as backup for first few months
Budget for testing edge cases in each target market

Risk Mitigation

Implement circuit breaker patterns for API failures
Robust retry logic with exponential backoff required
Monitor actual processing costs vs quoted rates
Custom fraud rule tuning necessary for production
Separate compliance requirements for marketplace sub-merchants

Support and Documentation Quality

Documentation Gaps

Edge cases poorly documented
Test card scenarios incomplete
Apple Pay simulator support limited
FX rate update frequency unclear
Marketplace payment flows assume regulatory knowledge

Support Response Times

Basic: 24-48 hours
Enterprise: Faster but often bounced between tiers
During outages: Poor communication vs Stripe's status updates
Technical issues require escalation to reach qualified support

Real-World Performance Data

Authorization Rates

APAC markets: 5-10% improvement with local acquiring
Europe: Better 3DS exemption handling
Global: Routing optimization requires manual tuning

Cost Analysis Example

Reported case: 40 basis points savings goal
Actual outcome: $30K engineering overhead + $8K revenue loss
Break-even requires sustained high volume and stable operations

This technical reference provides the operational intelligence needed for informed decision-making about Checkout.com integration, including failure modes, resource requirements, and true competitive positioning.

Useful Links for Further Investigation

Resources That Actually Help (Not Marketing Fluff)

Link	Description
API Reference	Their API docs are decent but the examples are too simple. You'll live in Stack Overflow once you hit edge cases.
Webhook Guide	Critical for handling payment events properly. Bookmark this, you'll need it when their webhooks inevitably break.
3D Secure Authentication	Required reading for European compliance. Way more complex than Stripe's approach.
Error Codes Reference	Bookmark this, you'll need it constantly for decoding their cryptic error messages.
Payment Geeks Slack	An active community Slack channel where payment professionals engage in discussions about real-world problems and solutions, offering unfiltered insights.

Checkout.com Payment Processor: Technical Integration Guide

Configuration Requirements

Onboarding Timeline

Critical Settings

Resource Requirements

Development Time Estimates

Volume Thresholds for Economic Viability

Hidden Cost Factors

Critical Warnings

Production Failure Modes

Breaking Changes Without Notice

Geographic Limitations

Technical Specifications

API Performance

Payment Method Support

Integration Complexity

Decision Framework

Choose Checkout.com When:

Avoid When:

Competitive Positioning

Common Implementation Issues

Error Handling

Dashboard Limitations

Webhook Debugging

Migration Considerations

From Stripe

Risk Mitigation

Support and Documentation Quality

Documentation Gaps

Support Response Times

Real-World Performance Data

Authorization Rates

Cost Analysis Example

Useful Links for Further Investigation

Resources That Actually Help (Not Marketing Fluff)

Related Tools & Recommendations

Payment Processors Are Lying About AI - Here's What Actually Works in Production

Stripe vs Plaid vs Dwolla - The 3AM Production Reality Check

What These Ecommerce Platforms Will Actually Cost You (Spoiler: Way More Than They Say)

Stop Stripe from Destroying Your Serverless Performance

Supabase + Next.js + Stripe: How to Actually Make This Work

Adyen for Small Business - Why You Should Probably Skip It

Adyen - Enterprise Payment Processor That Actually Works at Scale

Braintree - PayPal's Payment Processing That Doesn't Suck

Shopify Plus Costs $2,300+ Per Month - Here's What You Actually Get

Stripe + Shopify Plus Integration: When Standard Payments Aren't Enough

Shopify Admin API - Your Gateway to E-commerce Integration Hell (But At Least It's Documented Hell)

Stripe WooCommerce Integration - Doesn't Completely Suck (Unlike PayPal)

WooCommerce - The WordPress Plugin That Breaks Every Black Friday

Square - Developer Platform for Commerce APIs

Stripe vs Adyen vs Square vs PayPal vs Checkout.com - The Payment Processor That Won't Screw You Over

BigCommerce Enterprise - When Shopify's Transaction Fees Are Bleeding You Dry

Aider - Terminal AI That Actually Works

Plaid - The Fintech API That Actually Ships

Plaid Alternatives - The Migration Reality Check

Sift - Fraud Detection That Actually Works