High Risk Providers

High-Risk Providers

Some providers mainly serve merchants in high-risk or regulated sectors: subscriptions, adult content, iGaming, travel, CBD and others. Their integrations look different from a typical card checkout: many rebills, form-encoded postbacks, wallets, deposits and payouts, and frequent chargebacks. PandaPayLens supports a growing set of them.

PandaPayLens is a diagnostic tool. It is not a merchant account, referral, underwriting or approval service. Listing a provider implies no partnership or endorsement. Whether a provider accepts a merchant depends on jurisdiction, licensing, acquiring arrangements and the provider's own policies, never on anything shown here.

Waves

High-risk providers are added in waves, each released separately:

Wave	Providers	Status (0.4.0)
HR-1	CCBill, Segpay, Verotel, NETbilling, PXP Financial, Trust Payments	released, limited
HR-2	emerchantpay, Ecommpay, Paymentwall, NMI, MiFinity, AstroPay, Skrill, eZeeWallet	released, limited
HR-3	Finrax, Inpay, DECTA, Trustly	released, limited
-	Pavilion Payments, Epoch	blocked: no public developer docs

Research method

Every candidate passes the same gate before an adapter is written:

1. Only first-party sources: website, developer portal, API reference, official SDKs and PDF guides.
2. No logins, no access requests, no reverse engineering, no invented fields or codes.
3. Ten checks: active service, accessible documentation, identified API family, formats that can be examined offline, documented sectors, regional limits, real diagnostic value, an independent technical format, and no credentials needed.
4. Outcome: documentation verified, research only, or blocked.

Sectors are recorded only as the provider states them, each with a source link. The full method is in docs/providers/high-risk/research-brief.md, and the research for each provider is in docs/providers/high-risk/research/.

Lifecycle concepts

Concept	Normalized as	Notes
Initial charge or signup	payment
Rebill (recurring charge)	payment, recurring	a failed rebill triggers RECURRING_PAYMENT_FAILED; a provider retry date is shown
Cancellation, expiry, upgrade, downgrade	subscription/cancellation	expiry often has no reason, and none is guessed
Refund or credit	refund	an initiated refund is not a completed one (REFUND_PENDING)
Chargeback or dispute	dispute	CHARGEBACK_REPORTED, linked to the payment when the records show it
Payout (for example a gaming withdrawal)	payout	failed or unconfirmed payouts are reported by PAYOUT_STATUS
Wallet or bank transfer	the provider's own operation	a wallet approval is never treated as a card authorization

Common webhook problems

• No event id or timestamp. Many postbacks carry neither. Duplicates and ordering then cannot be checked, and the result says so.
• Event type outside the body. CCBill puts the event type only in the URL. Paste the raw HTTP request or the full URL.
• GET postbacks. Verotel and Paymentwall can send data in the query string. Paste the full URL.
• Merchant-configurable fields. Segpay, Trust Payments and Ecommpay let merchants rename or drop fields. Only documented defaults are read.
• Payouts and payments share one shape. Skrill status posts look the same for both; the operation is marked as uncertain when the payload cannot tell them apart.
• Unverified by design. Signatures are hidden and never checked.

Filters on the site

The providers page has focus filters (high-risk, gaming, subscription, wallet, pay-by-bank, gateway and acquiring). The examples page groups high-risk examples separately. These groups describe the provider's documented focus and never say anything about a specific merchant or transaction.