Cybersource

Adapter 0.1.0, documentation reviewed 2026-10-25. Overall status: limited.

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by event type with a fingerprint of the webhook id, the event date and the payload (transactionTraceId is new on every retry attempt, so it is not used); Cybersource documents that notifications can be delivered more than once.
• Delivery order: not documented by the provider.
• Cybersource retries a notification when the endpoint does not respond and gives every attempt a new transactionTraceId, so the trace id cannot be used to detect repeats. Make the handler idempotent on the transaction id inside the decrypted payload and the event type, and confirm the transaction state with Transaction Details before acting.

Known limitations

• Payment event and Unified Checkout notifications require message-level encryption, and the decrypted payload of card payment events is not documented. Such notifications are placed on the timeline by their event type only: they carry no readable transaction id, amount or reason, so they cannot be linked to other records.
• Two encryption formats are documented (JSON Web Encryption in the webhook guide, a {CBC}-prefixed string in the Pay by Bank example); neither can be decrypted offline. REST responses wrapped in encryptedResponse are recognized but not analyzed.
• There is no stable notification id. Repeated deliveries are recognized only when the event type, webhook id, event date and payload (or ciphertext) are identical; whether a retried payment notification keeps the same ciphertext is not documented. Acknowledgement rules, delivery order and the requestType value of a retry are not documented.
• The webhook eventDate carries no time zone, so it is shown as supplied and not used to order events.
• payments.authorization.status.rejected also covers SERVER_TIMEOUT and SERVICE_TIMEOUT, whose real outcome is unknown; with an encrypted payload the actual status cannot be read. payments.credit.status.updated repeats the description of the accepted event and is shown with an unknown outcome. Event types without payment semantics (risk, invoicing, token management) are shown without amounts or references; payload fields of recurring billing and Pay by Link events are not documented.
• Follow-on responses (capture, reversal, refund, credit, void) do not echo the id of the original payment; only the request path and the Transaction Details rootId link them. Pasted responses are therefore linked only by their own request id, by Transaction Details rootId and relatedTransactions links, and by the same id on incremental authorizations. clientReferenceInformation.code is merchant-defined and only optionally unique, so it is never used as a key.
• The operation of a response is read from _links (self, capture, authReversal, void), from the service-specific amount object or from the status. Refunds and stand-alone credits share the /pts/v2/credits/ resource and cannot always be told apart. A DECLINED or AUTHORIZED response without _links is shown as a payment, although refund, credit and payout responses use the same statuses. A PENDING response without _links is shown as an unidentified follow-on operation.
• Settlement is not a payload state: a capture or refund PENDING means accepted and waiting for the batch, BATCHED means sent to the processor, and Cybersource is not told when funds move. Chargebacks appear only in Reporting API records, which are not analyzed.
• processorInformation.responseCode depends on the processor (30+) and Cybersource says not to use it to evaluate the result; it is shown verbatim and not decoded. AVS and CVN results are shown as codes only, because the same letter can mean different things for Cielo and Latin American Processing.
• Reason codes are decoded from errorInformation.reason (HTTP 201) or the top-level reason (HTTP 400 and 502). Values that appear only as OpenAPI enum names are decoded with possible confidence, DAGGREJECTED, DAGGDENIED and DSYSREJECTED with insufficient confidence. PROCESSOR_ERROR has conflicting descriptions (pick up card versus Invalid account) and is decoded with possible confidence.
• Payment insights categories are Cybersource's own retry advice and replace the reason's retry guidance on declines. Merchant advice codes are told apart by format (one digit for Visa, two for Mastercard, 00 to 05 for Barclays); when present, the stricter guidance is used. The documented example of a successful authorization carries category 01, so categories are only applied to declines.
• Transaction Details records are built from the documented field list; no complete example was reviewed. Amounts are not read from them. Only service names that match a REST service (ics_auth, ics_auth_reversal, ics_credit, ics_void) get a lifecycle stage; ics_bill, ics_decision and other names are shown without one. Numeric reason codes are decoded from the reason code table; code 267 is cited in the timeout guidance but missing from the table and is decoded with possible confidence. The rFlag vocabulary is not documented.
• Pay by Bank statuses are documented by name only; their stage and outcome follow the names. The decrypted payload uses the misspelled key reconcillationID, which is not read.
• HTTP 429 and 503 load-shedding responses, Secure Acceptance form posts, the Simple Order API, payouts-specific fields and Reporting API records are not analyzed. Plain-text error bodies are not documented and are not claimed.
• Category and retry guidance per reason are PandaPayLens suggestions that follow Cybersource's recommended actions where given. A timeout or SERVER_ERROR is never shown as safe to retry: Cybersource asks to check the status first and may reverse the authorization automatically.
• Webhook signatures (v-c-signature) cannot be verified from pasted payloads and are never copied; a pasted notification is never treated as authentic.

Examples

• Cybersource: authorization, capture and refund: Three operations linked into one timeline through the Transaction Details root id.
• Cybersource: declined, insufficient funds: An HTTP 201 decline decoded with Cybersource's retry advice.

Provider documentation

• Transaction response codes
• Response code file (status, reason, recommended action)
• Payments Developer Guide (REST, Visa Platform Connect)
• Reason codes (numeric)
• Webhooks Implementation Guide
• REST API getting started (authentication, message-level encryption)
• Transaction Search and Details API
• REST API field reference
• AVS codes
• CVN codes
• Pay by Bank webhook notifications
• Official OpenAPI specification (Java SDK repository)

PandaPayLens is not affiliated with Cybersource. Pasted notifications are never treated as verified: PandaPayLens does not check webhook signatures.