Differentiator

Shadow Mode

Integrate with PAYKX and run the full Assessment Engine — against your real transaction patterns — without touching live payment rails. Zero risk. Real decisions.

Request API access Read the docs

🔒

No live rails touched

Every call runs the real seven-signal Assessment Engine. No money moves. No regulatory exposure. No risk to your customers.

⚡

Identical response shape

Shadow mode returns the same JSON structure as production. Your integration code is production-ready from day one.

🔁

Deterministic & reproducible

Same corridor + amount always returns the same decision. Your automated tests stay stable across every run.

📊

Real-world calibration

Run your historical transaction portfolio through the API in batch mode. Measure how many you'd have flagged before they failed.

What shadow mode is

Shadow mode (also called demo mode) is the current operating state of PAYKX Rail. Every API call is processed by the live Assessment Engine — the same engine that will power production decisions. The only difference is that no external payment rails, partner APIs, or regulated data sources are queried. All probes are evaluated against a high-fidelity deterministic model of the GB-NG corridor.

Why does this matter? Most fintech APIs require you to build against a toy sandbox that doesn't reflect real behaviour. PAYKX shadow mode uses the same engine, same signal weights, same decision thresholds, and same response structure as production — you are testing against the real thing.

Shadow vs live

Shadow mode (now)

Full Assessment Engine — all 7 signals
Deterministic, reproducible decisions
No auth required for demo endpoint
API key required for /api/v1/verify
No live partner probes
No regulated data queries
Ideal for integration and QA

Live mode (coming)

Full Assessment Engine — all 7 signals
Real-time partner health probes
Live settlement rail checks
Live FX volatility feeds
API key required (live key)
Higher confidence scores
Production SLA commitments

Platform maturity

PAYKX is in its design-partner phase. The table below documents current availability honestly — framed as an engineering roadmap rather than a list of missing features.

Capability Current status

Live signal providers PAYKX currently evaluates transactions using calibrated corridor baselines and deterministic operational signals. The Assessment Engine has been architected to ingest live signal providers as they become available — this is a data integration milestone, not an engine change. Planned.

Supported corridors Production-quality decision models are available for GB→NG and NG→GB. Requests for unsupported corridors return a DEGRADED verdict to indicate reduced decision confidence — not an error — ensuring integrations never receive misleading recommendations.

Identity model Authentication is API-key based. Multi-user organisations, role-based access, and account management are not yet implemented. During the design-partner phase, key issuance is handled directly by the PAYKX team.

Event-driven integrations Verification is currently synchronous — every call returns a decision inline. Webhook callbacks and asynchronous decision notifications are planned for future releases to support high-volume, event-driven integration patterns. Planned.

Service commitments PAYKX currently operates in demonstration and shadow-mode environments. Formal SLAs and uptime guarantees will be introduced alongside production availability. Shadow mode itself is high-availability — the Assessment Engine runs on autoscaled infrastructure.

Commercial controls Usage metering, quotas, and billing are not yet enabled. API access is currently managed directly during the design-partner phase — intentionally, to keep the evaluation experience frictionless while the commercial model is finalised. Planned.

Deployment steps

Request a shadow API key

Fill out the access request form. You'll receive a paykx-sandbox-**** key that works immediately against the shadow Assessment Engine.

Integrate against shadow

Point your integration at POST /api/v1/verify with your real corridor and amount data. Use idempotency_key to make retries safe.

curl https://api.paykx.co.uk/api/v1/verify \
  -H "Authorization: Bearer paykx-sandbox-****" \
  -H "Content-Type: application/json" \
  -d '{"corridor":"GB-NG","amount":1500,"currency":"GBP"}'

Run a batch audit

Upload 30–90 days of historical transactions to POST /api/v1/batch-assess. Review the alignment report — see which failures PAYKX would have flagged in advance.

Confirm integration health

Run your test suite. Every call with the same inputs returns the same output — your tests are stable by design.

Request a live key when ready

Once you're satisfied with the integration, contact taseenrayed@paykx.co.uk to discuss corridor exit from shadow mode and live key issuance.

Sample outputs

These are real responses from the shadow engine. The structure is identical to what you will see in production.

{
  "decision": "GO",
  "score": 0.94,
  "confidence": 0.97,
  "reason_codes": ["HEALTHY_PARTNER"],
  "request_id": "req_m3a7fzk2p1r4",
  "evaluated_at": "2026-07-19T10:00:00Z",
  "decision_model": "v1.2",
  "environment": "fca-sandbox-validated",
  "corridor_supported": true,
  "signals": {
    "balance_sufficient": true,
    "operation_valid": true,
    "network_healthy": true,
    "historical_failure_rate": 0.04,
    "cop_overridden": false,
    "fx_volatility": "low",
    "fraud_flags": 0
  }
}

Shadow mode is a feature, not a limitation. Many teams ship their integration in shadow mode first — monitoring decisions alongside their live rails — before switching the response over to drive actual payment routing. This is the safest way to adopt any new risk intelligence layer.