Is CyberSource down right now?

While you wait: the CyberSource incident checklist

1. Name the dependency precisely. CyberSource is your payment-processing dependency. Identify which of these surfaces is actually in the production path: checkout, authorization, settlement, subscriptions, refunds and payment webhooks.
2. Confirm the affected path. Use CyberSource's component and incident detail, then separate authorization failures from webhook or dashboard delays and verify whether the affected payment method or region matches your flow.
3. Bound every retry. Cap concurrency, use exponential backoff and retain idempotency where applicable. An upstream incident should not become a retry storm against CyberSource or your own services.
4. Use the rehearsed fallback. For this dependency, avoid blind payment retries, preserve idempotency keys and offer a safe retry-later path to customers. Do not invent a new failover path during the outage.
5. Verify recovery end to end. A green CyberSource status is the start of validation: reconcile ambiguous charges, delayed webhooks and order state before replaying any payment action.

What breaks when CyberSource has issues

CyberSource sits in the payments layer. An incident can affect checkout, authorization, settlement, subscriptions, refunds and payment webhooks; the exact blast radius depends on the components, regions and features your production path uses. Treat the official component timeline as evidence, compare it with your own independent probes, and communicate the user-visible effect rather than saying the whole vendor is simply “down.”