CyberSource

info

Use your current CyberSource implementation with Modo by changing only the host. This page shows a minimal‑change path and optional enhancements.

Overview

Modo routes CyberSource API calls through our platform while preserving your payloads, headers, auth, and error codes. We call this an API “Transpose”: you swap the hostname; we mirror the rest.

Frontend Integration

CyberSource REST flows often don’t require a browser script. If you use Secure Acceptance or Flex Microform, you likely load a script and hosted fields.

tip

Option A: Minimal change (Flex Microform)

Replace the Flex script tag only. Your initialization code and usage remain unchanged.

Replace:

<script src="https://flex.cybersource.com/cybersource/assets/microform/1/lib.js"></script>

With:

<script src="https://js.api.modopayments.io/cybersource.js"></script>

note

Option B: Use Modo Elements (optional)

• Unified, processor‑agnostic input components
• Centralized tokenization + routing logic
• Easy fallback/backup routing

Backend Integration

Change the base URL only. Headers, bodies, and auth stay the same.

Replace:

https://api.cybersource.com/

With:

https://cybersource.api.modopayments.io/

Authentication

CyberSource supports HTTP Signature and OAuth. Modo supports:

• Signature passthrough (no changes)
• Optional centralized credential storage
• Key masking/rotation with Vault integrations

Supported Endpoints

Common endpoints work out of the box with passthrough semantics.

Endpoint	Support
/pts/v2/payments	Full passthrough
/pts/v2/credits	Supported
/reporting/v3/reports	Optional (opt‑in)
/risk/v1/decisions	Supported

For a full compatibility matrix, contact your implementation team.

Versioning

We mirror the CyberSource API versions you currently use. You can upgrade later without blocking migration.

Compatibility Notes

• Webhooks: keep your existing URLs; we can forward or normalize.
• Flex keys: ensure your public key mapping is configured in Modo.
• Error codes: preserved unless you opt into normalization.
• Retries: optional resilient retry is available.

Examples

Create a Payment (REST)

curl https://cybersource.api.modopayments.io/pts/v2/payments \
  -H "v-c-merchant-id: your_merchant_id" \
  -H "Date: ..." \
  -H "Host: api.cybersource.com" \
  -H "Signature: keyId=...,algorithm=...,headers=...,signature=..." \
  -H "Content-Type: application/json" \
  -d '{
        "clientReferenceInformation": {"code": "test_payment"},
        "paymentInformation": {"card": {"number": "4111111111111111", "expirationMonth": "12", "expirationYear": "2030"}},
        "orderInformation": {"amountDetails": {"totalAmount": "10.00", "currency": "USD"}}
      }'

Retrieve a Transaction

curl https://cybersource.api.modopayments.io/pts/v2/payments/{id} \
  -H "v-c-merchant-id: your_merchant_id" \
  -H "Signature: ..." \
  -H "Content-Type: application/json"

Going Further

• Add secondary processors as fallback
• Route based on geography, card data, or metadata
• Centralize reporting, logging, and observability

FAQ

Can I keep HTTP Signature? Yes, passthrough works without changes.

What about webhooks? Keep your current URLs or route via Modo for transformation/reliability.

Will Flex tokenization change? Only the script URL; behavior and callbacks remain the same.

Can I add another processor later? Yes—routing/fallbacks are first‑class.