Skip to content

FAQ

Performance & Reliability

Does PulseRoute add latency to my payment flow?

Negligible. The routing decision is a single HTTP call that resolves in 1-5ms in a colocated deployment. For context, a typical Stripe charge takes 300-800ms — PulseRoute adds less than 1% to that.

The SDK also caches the last routing decision locally. If PulseRoute is temporarily unreachable, the cached decision is returned instantly with zero added latency.

What happens if PulseRoute goes down?

Your payments continue unaffected. The SDK is designed for resilience:

  1. Local cache: The SDK caches the last routing decision. If the API is unreachable, it returns the cached decision immediately.
  2. Fire-and-forget outcomes: Outcome reports are buffered in memory and flushed asynchronously. If the API is down, outcomes are queued and sent when connectivity returns.
  3. Graceful degradation: If PulseRoute is completely unavailable and has no cached decision, your application falls back to its default routing logic.

PulseRoute is an intelligence layer, not a hard dependency. Your payment processing never blocks on PulseRoute availability.

How fast does PulseRoute detect failures?

  • Sudden outage (processor goes completely down): 5-15 seconds
  • Gradual degradation (error rate climbing slowly): 15-30 seconds with Tier 1, or 30-60 seconds early with Tier 2 prediction
  • Predictive detection (Tier 2): Detects degradation patterns before error rates visibly spike, typically 30-60 seconds ahead of threshold-based detection

Detection speed scales with your transaction volume — more transactions per second means more data points per evaluation cycle, which means faster detection.

Security & Compliance

Do you touch cardholder data?

Never. PulseRoute only processes routing metadata:

  • Processor IDs (e.g., "stripe", "adyen")
  • Transaction results (success or failure)
  • Latency (e.g., 145ms)
  • Error codes (e.g., "timeout", "declined")
  • Routing context (country, currency, payment method)

PulseRoute has no access to card numbers, cardholder names, addresses, transaction amounts, or any personally identifiable information. It's designed to operate entirely outside the PCI cardholder data environment (CDE).

Is PulseRoute PCI compliant?

PulseRoute is designed to operate outside the PCI-DSS scope. Since we don't process, store, or transmit cardholder data, PulseRoute does not increase your PCI compliance burden. Our SDK integration points are positioned around your payment flow (before and after), not within it.

How is tenant data isolated?

Each tenant has a completely separate data namespace. Routing rules, health metrics, predictions, bandit weights, and webhooks are fully isolated between tenants. There is no cross-tenant data access.

How do you handle API key security?

API keys are transmitted via HTTP headers (never in URLs), and all API communication uses TLS. We recommend rotating keys periodically and using separate keys for production and staging environments.

Integration

How long does integration take?

Most teams complete integration in 1-2 hours:

  1. 15 minutes: Run the onboarding wizard or call POST /v1/onboard to configure your processors and rules
  2. 30 minutes: Add the SDK to your payment flow (3 lines of code: init, getRoute, reportOutcome)
  3. 15 minutes: Verify with a few test transactions
  4. Optional: Set up webhooks for alerting, connect Grafana dashboard

Which processors do you support?

All of them. PulseRoute is processor-agnostic — it routes traffic between any payment processors you use. Common setups include:

  • Stripe + Adyen
  • Braintree + Stripe
  • Checkout.com + Adyen
  • Worldpay + Stripe

You define the processor topology; PulseRoute handles the routing intelligence.

Which languages do you support?

  • Node.js: Full SDK with TypeScript types, local caching, and outcome buffering
  • Python: SDK with sync and async support
  • Java: Integration via REST API (code examples provided)
  • Any language: Full REST API available for direct integration

Can I use PulseRoute with my existing payment orchestration platform?

Yes. PulseRoute is a routing intelligence layer, not a payment orchestration platform. It tells you which processor to use — your orchestration platform handles the actual payment processing. Integrate PulseRoute as the decision-maker upstream of your orchestration layer.

Getting Started

How long until I see value?

Start in shadow mode (recommended). PulseRoute observes your traffic and computes routing decisions without changing anything. Within 1-2 weeks of shadow mode observation, check the shadow report:

curl /v1/shadow-report?average_order_value=75

This shows exactly how many transactions PulseRoute would have routed differently, how many failures it would have prevented, and the estimated revenue impact. You'll have concrete data on PulseRoute's value before changing a single routing decision.

What's the pricing model?

Free during beta. After beta, pricing will be usage-based (per routing decision). We'll communicate pricing well in advance of any charges.

Can I try it without affecting production?

Absolutely. There are two ways:

  1. Shadow mode: Install PulseRoute in your production environment. It observes real traffic and computes decisions, but your existing routing remains unchanged. This gives you the most accurate impact data.

  2. Sandbox: Run PulseRoute locally with Docker Compose and the built-in simulator to see how it handles various failure scenarios. No production traffic involved.

Do I need to change my database or infrastructure?

No. PulseRoute runs as a standalone service (single Docker container + Redis). It doesn't require changes to your database, payment tables, or existing infrastructure. The SDK communicates with PulseRoute over HTTP — it's an API call, not an infrastructure migration.

Operations

How do I monitor PulseRoute itself?

PulseRoute exposes Prometheus metrics at /metrics and includes a pre-built Grafana dashboard. Key metrics to watch:

  • Processor health status per rule
  • Success rates per processor
  • Failover events
  • Routing decision latency
  • Engine tier status

See Observability for the full metrics reference.

Can I tune the failover thresholds?

Yes. All thresholds are configurable:

  • When to consider a processor "degraded"
  • When to trigger failover
  • When to consider a processor "recovered"
  • Prediction sensitivity (Tier 2)
  • Minimum traffic allocation (Tier 3)

Tiers can also be toggled at runtime without restart — start with Tier 1 and enable higher tiers when you're ready.

What if both processors are unhealthy?

PulseRoute routes to whichever processor is performing least badly. Tier 3 (Autopilot) handles this gracefully by allocating traffic proportionally to each processor's success rate. Even in a dual-degradation scenario, PulseRoute optimizes for the best possible overall success rate.