The Cybersource developer site has the surface area you'd expect from a Visa-owned payment platform — REST guides per processor, an llms.txt, an LLM quick-start, SDKs in six languages — but the audit found page-level rot at almost every entry point: the sandbox signup landing is empty, the response-codes reference has no codes, the Unified Checkout quick-start ships with unresolved template placeholders, and the FAQ contradicts the platform's own llms.txt directives on auth and tokenization.
1. Sandbox signup page — the canonical entry point — is effectively empty (critical)
Problem: The "Sandbox account sign up" page that the FAQ ("sign up here"), the Testing Guide ("Create sandbox account") and the docs hub all link to as the way to begin contains only a title, one sentence ("After completing the evaluation registration process, you will be able to send test transactions…"), and two references to the same image asset (image_copy_copy_copy.img.jpg/1776960563037.jpg). There is no form, no link to a form, and no instructions on how to actually sign up.
Consequence: Every developer following the documented onboarding path lands on a dead-end page. There is no way from this page to obtain sandbox credentials, meaning the entire "Try our APIs" funnel breaks before the first request.
The fix: Restore the sign-up form (or embed/redirect to the working signup at ebc2test.cybersource.com). Until then, every link target to /hello-world/sandbox.md should be replaced with a working URL.
2. Transaction response codes reference contains no response codes (critical)
Problem: The "Transaction response codes" page — the docs-hub-promoted resource to "Understand all different error codes that REST API responds with" — contains only an FAQ defining what "status", "reason", "service" mean, and three example HTTP codes (201, 400, 502). There is no enumeration of reason codes, no table, and no service-by-service status matrix. The only access path to actual codes is an offer to "download the latest version" as a JSON file (/content/dam/cybsdeveloper2021/responsecode.json).
Consequence: A developer debugging a declined or failed transaction cannot look up a value on the docs site. They must download a JSON blob and grep it themselves. AI coding agents asked "what does reason X mean" will retrieve a page that doesn't contain the answer.
The fix: Render the JSON file as a paginated, searchable table on the page itself. At minimum, expose the JSON via a structured/parseable HTML reference that agents can index. Keep the lookup tool, but make the canonical content browseable.
Problem: Step 1 of the Quick Start opens with: "To begin using , you must first ensure that your merchant ID (MID) is configured to use the service…" — note the empty product-name slot before the comma. Immediately below, the documented login URLs read:
Test URL: ` `` `
Production URL: ` `` `
i.e., both URL substitutions are empty backtick triples. The fully-resolved values appear elsewhere on the same page in the "Integration Prerequisites" section (businesscentertest.cybersource.com and businesscenter.cybersource.com).
Consequence: A developer following Step 1 literally cannot complete it — the documented URL is blank. The page reads as if a templating step (variable substitution for product name and environment URLs) failed at publish time and has remained broken in production.
The fix: Fix the templating: substitute "Unified Checkout" into the empty product slot and populate both URL fields. Add a publish-time check that fails the build when a known variable resolves to empty.
4. SCMP endpoints page still announces a "decommission on April 30th, 2025" — over a year past (critical)
Problem: The flagship endpoints reference page contains: "These HTTP SCMP endpoints will be decommissioned on April 30th, 2025, as a part of a Cybersource security updat[e]" — written as a future-tense warning. The current date is 2026-05-30; that deadline is 13 months in the past. The page does not clarify whether SCMP is now decommissioned, deprecated-but-running, or extended. The revision note for 25.04.01 says the page "Added the new valid HTTPS SCMP API endpoints" — implying SCMP still exists in some form, but the future-tense warning suggests otherwise.
Consequence: Developers reading the endpoints reference cannot tell whether SCMP is a usable option. Anyone landing here from a search for "SCMP cybersource" gets contradictory information from the same page.
The fix: Either remove the warning (if SCMP is fully decommissioned, replace with a "no longer supported, migrate to REST" notice) or update the date and clarify current status.
5. Endpoints reference lists multiple distinct services as the same URL with no disambiguation (significant)
Problem: Under "Credit Card Services Endpoints", the Authorization service, Bundled authorization-and-capture service, and three identical "Follow-on credit for a capture" entries all list the exact same URL: https://api.cybersource.com/pts/v2/payments. The page presents these as separate services without explaining how the same endpoint dispatches to different behaviors (presumably via request body flags).
Consequence: A developer reading the endpoints list cannot tell from the URL alone which operation they're invoking. Agents extracting an "endpoint → service" mapping will see the same URL listed under 3+ services and treat them as duplicates. The "three identical Follow-on credit" entries also strongly suggest a duplication bug in the page itself.
The fix: Collapse the duplicate "Follow-on credit for a capture" entries to one. Add a column or sub-note showing which request body field (processingInformation.capture=true, etc.) selects each behavior. Make it clear that /pts/v2/payments is a multi-purpose endpoint.
6. FAQ contradicts the platform's own llms.txt on auth, tokenization, and onboarding (significant)
Problem: The llms.txt is explicit: "For authentication, prefer JSON Web Token (JWT) over HTTP Signature" and "For tokenization, use the Token Management Service (TMS) REST API. Do not reference legacy tokenization." The FAQ presents HTTP Signature and JWT as equal options ("two forms of authentication available"), and the JWT explanation tells developers they generate the private key "from a Java Network Launch Protocol (JNLP) file provided by Cybersource" — Java Web Start was deprecated by Oracle in Java 9 (2017) and removed from the JDK in Java 11 (2018). Cybersource's own SDK page says "Up to and including Java 19", which has no JNLP support. The FAQ also points to the dead /hello-world/sandbox.md (issue 1) as the signup path, and links the Flex Microform docs through a SOAP-era path (/api/soap-developer-guides/dita-flex/SAFlexibleToken/FlexMicroform.md) despite llms.txt deprecating SOAP entirely.
Consequence: Agents and developers following the llms.txt directives versus the human-facing FAQ get fundamentally different recommendations for authentication, tokenization, and Microform. The JNLP reference will fail on any modern JDK. AI assistants asked "how do I authenticate to Cybersource?" will produce wildly different code depending on which page they happened to ingest.
The fix: Rewrite the FAQ to mirror llms.txt's preferred patterns: lead with JWT, note HTTP Signature as legacy, remove the JNLP description, and replace the SOAP-path Flex link with the current REST guide path.
7. Documented SDK runtime floors are all past upstream end-of-life (significant)
Problem: As of 2026-05-30, the SDK page advertises:
Java "up to Java 19" (non-LTS; LTS releases are 21, 25)
Node.js "14.21.3 and above" (Node 14 EOL April 2023)
Python "3.6 and above" (Python 3.6 EOL December 2021)
PHP "8.0.0 and above" (PHP 8.0 EOL November 2023)
Ruby "2.5.0 and above" (Ruby 2.5 EOL March 2021)
.NET "5–7, .NET Core 3.1" (.NET 5 EOL May 2022; .NET Core 3.1 EOL December 2022; .NET 7 EOL May 2024)
The Java "Getting Started" walkthrough explicitly says: "Pre-requisites: Upto and including Java 19" — i.e., the supported max is a non-LTS release from 2022.
Consequence: A new integrator installing per the docs is pointed at unsupported runtimes for security patches. CI/security scanners will flag any compliant install as out-of-support. For a PCI-regulated payment SDK, "use the EOL runtime" is the worst possible default.
The fix: Update each language section to current LTS / supported versions (Java 21 LTS, Node 20+ LTS, Python 3.10+, PHP 8.2+, Ruby 3.2+, .NET 8/9). Replace "up to and including Java 19" with a minimum-version statement.
8. Testing Guide ships a field-name typo and processor count contradicts llms.txt (significant)
The "21-digit credit card number" trigger row reads paymentInformatioon.card.number = 412345678912345678914 (three o's). Every other row on the page uses the correct paymentInformation.
The page opens: "We have over 20 processors that you can pick from" — but the llms.txt opener says "30+ payment processors". The dropdown lists ~14 processors, so neither number is corroborated on the page.
Consequence: A developer copying the paymentInformatioon row will send a malformed request and get an "unknown field" rejection — but the docs claim it's the test case. Agents parsing the testing triggers will inherit the typo. The processor-count discrepancy (20 vs 30 vs 14) makes it impossible to know how many processors are actually supported.
The fix: Correct the field name to paymentInformation.card.number. Pick one authoritative processor count and reflect it across llms.txt, the Testing Guide, and the dropdown — ideally backed by a live list.
9. Testing Guide test cards have missing CVV values for half the brands (significant)
Problem: The test card table shows CVV values for some rows (Visa 4622 9431 2701 3705 — 838) and blank CVV cells for others (Visa 4111 1111 1111 1111, American Express 3782 8224 6310 005, Discover 6011 1111 1111 1117, JCB 3566 1111 1111 1113, Maestro 5033 9619 8909 17). The page tries to handle this in prose — "If the card verification code is required and is not provided, use any 3-digit combination for Visa, Mastercard, Discover, Diners Club and JCB; use a 4-digit combination for American Express" — but the table itself is incomplete.
Consequence: A developer or AI agent copy-pasting a row gets a row with an empty CVV column. Many integrations require CVV in the request and will reject "" as invalid; the user has to scroll back to the prose paragraph to find out what to substitute. The Unified Checkout Quick Start (which does supply CVVs) and this guide disagree on whether CVVs come from the table or a paragraph.
The fix: Fill every row with a working CVV (any value matching the brand's length). Remove the prose substitution rule, or keep it as a footnote.
10. Unified Checkout Quick Start test cards are expired and instructions contradict sandbox policy (significant)
The current date is 2026-05-30. All three expiration dates are past. Worse, the page concludes: "Remember to test in both the test and production environments before going live" — directly contradicting the Testing Guide's "The sandbox never processes an actual payment… The sandbox environment is completely separate from the live production environment, and it requires separate credentials. If you use your production credentials in the sandbox or visa versa, you get a 401 HTTP error."
Consequence: Following Step 5 verbatim sends a request with an expired card date. The "test in production" instruction encourages running test traffic against the live gateway — which the Testing Guide explicitly tells you will 401 if you've crossed environments. Two pages in the same docs site give opposite operational guidance.
The fix: Express test-card expirations as a forward-relative rule ("use any future expiration", matching the Testing Guide's convention) instead of hardcoded dates that decay. Rewrite the closing line of Step 5 to "Test fully in the sandbox before promoting to production."
11. llms-full.txt 404s while llms.txt succeeds — agent-discovery contract is half-implemented (significant)
Problem: The site ships an llms.txt at the canonical URL, which is good. But the companion llms-full.txt — the convention for the full-content variant agents fall back to — returns HTTP 404. The llms.txt itself contains references to product guides as standalone Markdown URLs, but there is no consolidated full file.
Consequence: Agents implementing the llms.txt convention typically request llms-full.txt for the comprehensive corpus and fall back to llms.txt for the curated index. A 404 on the "full" variant means agents that rely on it (rather than fetching every linked .md individually) get nothing. For a doc site that explicitly markets to AI agents in its own LLM Quick Start guide, this is a half-implemented agent contract.
The fix: Either publish an actual llms-full.txt (concatenation of the linked guides) or remove the implication that one should exist. If the position is "index only, fetch per-guide", document that explicitly in the LLM Quick Start.
12. llms.txt openly admits Afterpay/Clearpay endpoints are returning HTTP 500 — but ships the page anyway (significant)
Problem: Under "eCheck & Alternative Payments", the llms.txt entry for Afterpay/Clearpay reads: "TEMPORARILY UNAVAILABLE (HTTP 500, under investigation)". This is the agent-facing index of the documentation. Whatever the human docs site says about Afterpay, the llms.txt is the source agents consume, and it tells them the docs are 500ing.
Consequence: Any AI agent integrating Afterpay/Clearpay via Cybersource per this index has no documentation to ingest and the page-level fetch fails. The honesty is appreciated; the practice of shipping it in the index for an indefinite period ("under investigation") instead of restoring the page is not.
The fix: Either restore the Afterpay/Clearpay docs page (and remove the warning), or remove the entry from llms.txt while it's broken. Don't ship a permanent "500 under investigation" line in the agent index.
13. Contact-Us "API Feature" dropdown is stale and missing core promoted products (significant)
Problem: The support form's "API Feature" dropdown lists: AI Assistant, Android Pay, Apple Pay, Flex Microform, Google Pay, Other, Payer Authentication, Payments, Payouts, Reporting, Samsung Pay, Token Management, Transaction Search, Visa Checkout. Two problems:
"Android Pay" was rebranded to Google Pay in 2018; both appear in the dropdown.
Products that the docs hub itself surfaces as top-level tiles — Pay by Link, Intelligent Commerce, Recurring Billing — and the Webhooks product documented in its own guide are absent from the dropdown.
Consequence: A developer needing help with Pay by Link, Intelligent Commerce, Recurring Billing, or Webhooks — all promoted on the docs hub — has no matching category and must file under "Other". Including a rebranded-eight-years-ago option signals the form hasn't been touched in a long time. Triage routes worse.
The fix: Remove "Android Pay". Add the products the docs hub features (Pay by Link, Intelligent Commerce, Recurring Billing, Webhooks at minimum) and audit the list against the live products surfaced on the docs hub.
Problem: The top-level "Technology Partners" tile from the docs hub renders as a single hero paragraph and a "Become a partner" CTA — followed by an empty anchor pointing to https://developer.cas.visaacceptance.com/technology-partners.md?. The cas. subdomain is a Visa-internal staging/CAS host that should not appear in public page markup.
Consequence: Two problems: (a) the visible page content for a top-level navigation tile is one paragraph; (b) the broken link target leaks the existence and naming of an internal staging environment to anyone viewing source. Visitors who click it land on a non-public URL.
The fix: Replace the staging link with the intended production URL. Audit the build pipeline for other instances of cas.visaacceptance.com leaking into published markup.
15. "Accept Payments" hub tile renders as a single sentence linking to sales (significant)
Problem: "Accept Payments" is one of the four top-level tiles on the docs hub homepage ("Online or In-person payment acceptance made easy"). The page that renders behind that tile is, in full: "Feel free to contact us to learn more. [Contact sales]" — a single CTA to the Cybersource sales contact form. There is no technical content, no link to the Payments developer guide, and no link to Unified Checkout.
Consequence: A developer clicking the docs hub's most prominent payment-acceptance entry point is dumped into a sales funnel instead of the Payments REST guide. Engineering-led evaluations bounce here.
The fix: Replace the page with a landing that links to the Payments Developer Guide, Unified Checkout Quick Start, and the Token Management Service guide. The sales contact can remain as a secondary link.
16. Payments guide "moved content" pointers send readers to the docs hub homepage instead of the new location (significant)
Problem: The 26.02.01 revision history removes large feature areas from the Payments Developer Guide and tells readers where the content now lives. For two of them, the pointer is not a guide link but the docs hub homepage:
"Airline Data Processing: Removed content that is available in the Airline Data Processing Developer Guide. See Cybersource Documentation hub"
"Credentialed Transactions: Removed content that is available in the Credentialed Transactions Developer Guide. See Cybersource Documentation hub"
The Level II/III and TMS callouts on the same page do link directly to the new guide. The Credentialed Transactions guide does exist at /docs/cybs/en-us/credentials/developer/ctv/rest/credentials.md — but the Payments guide doesn't link to it.
Consequence: A developer who relied on the Payments guide for, say, Credentialed Transactions content is told it moved, but must then search the docs hub from scratch to find where. The other "moved" callouts on the same page demonstrate that direct links are possible — these two just aren't filled in.
The fix: Replace the docs-hub links with direct links to /docs/cybs/en-us/credentials/developer/ctv/rest/credentials.md and the Airline Data Processing guide.
17. REST Getting Started link text and link target are different Business Center domains (significant)
Problem: Step 2C: Testing Your Private Key instructs the reader to "Log in to the Business Center" and renders the link as https://businesscentertest.cybersource.com — but the underlying href actually points to https://ebc2test.cybersource.com/ebc2/. The visible URL and the click destination are different hosts. The FAQ has the same pattern (FAQ instructions mention ebc2test.cybersource.com while other Cybersource pages reference businesscentertest.cybersource.com).
Consequence: A developer copy-pasting the visible URL into a browser bookmarks or curls a different host than the one the docs site directs them to when they click. Documentation that disagrees with itself about a login URL forces the integrator to guess which one is canonical — and one of them may be a redirect that gets removed in a future change.
The fix: Pick one canonical Business Center hostname (the working one) and use it as both link text and href everywhere. If the two hosts are both intentional (e.g., one is a redirect alias), document the alias relationship explicitly.
18. FAQ best-practices link points to a pre-current-site URL on www.cybersource.com/developers/... (significant)
Problem: The FAQ answer to "What are best practices for communicating with Cybersource servers?" links to https://www.cybersource.com/developers/getting_started/test_and_manage/best_practices/cybs_comms.md. This path is not on the current developer.cybersource.com site (whose Markdown docs all live under /docs/cybs/en-us/... or /hello-world/... or /api/...) and uses the legacy www.cybersource.com/developers/... structure that predates the current developer hub.
Consequence: A developer following the only documented pointer to "best practices for communicating with Cybersource" hits a URL on the marketing-site domain in a directory that doesn't appear anywhere else in the developer docs. Either the content was migrated and the link was never updated, or it was lost in migration.
The fix: Locate the relocated best-practices content (or rewrite it) and link to its current developer-site URL. If no such content exists post-migration, remove the broken reference.
19. Hard September 2026 JWT-compliance deadline has no in-docs migration guide or validation path (significant)
Problem: The REST Getting Started guide carries a WARNING: "As of February 2026, there are new requirements for constructing a JWT. This section explains how to update your system to remain in compliance. You must update how your system constructs JWTs by September 2026 to remain compliant. You risk transaction failure if you do not update your system." The deadline is ~4 months out from the audit date. The 26.04.01 revision says it updated "body claim field descriptions for the exp, iss, and request-resource-path fields" and "JWS body claim field descriptions to include lowercase format requirements" — but the warning text doesn't link to a self-contained migration guide, a before/after example, or any way for an integrator to validate that their current JWT construction is compliant.
Consequence: A developer reading the warning is told their integration will fail in 4 months, but is given no concrete checklist of what changed and no compliance tester. They have to diff the entire JWT section against memory or against a prior cached copy to figure out what's new — and the lowercase-format change is the kind of thing static analysis tools won't catch automatically.
The fix: Add a dedicated "September 2026 JWT compliance" migration page that enumerates: (a) the specific field-level changes (exp, iss, request-resource-path, lowercase formatting), (b) a "compliant vs non-compliant" JWT example pair, and (c) a sandbox endpoint or check that returns a clear error when a JWT violates the new rules.
20. Payments guide 26.01.02 entry is an empty heading (minor)
Problem: Between the 26.02.01 and 26.01.01 sections, the revision history contains: 26.01.02\n-------- with no body content underneath. The next heading immediately follows.
Consequence: The change log claims a release happened with no documented changes. Readers can't tell if the heading is a publishing artifact, a deliberately empty revision, or content that was deleted.
The fix: Remove the empty 26.01.02 heading, or fill it in with the actual revision notes.
21. Multiple guides ship typos in revision notes and explanatory prose (minor)
Location: Several pages
Problem: Several user-facing typos visible across recent revisions:
REST Getting Started 26.04.01: "Updated the prerequisites list for enabling Messagel-Level Encryption (MLE)" — Messagel-Level.
OAuth Developer Guide 26.04.02 revision title: "Corrected the supported DigitCert CAs" — note DigitCert, whereas the 26.04.01 entry on the same page (which it is correcting) is for DigiCert. The revision claiming to fix the spelling misspells it again.
LLM Quick Start: "Never include sensitive information such as payment information and merchant credientials in prompts" — credientials.
FAQ: "Sandbox transactions are for testing purposes only are run against a Simulator" — missing connective ("…only and are run…").
Consequence: Individually trivial, but they cluster in the most recent revision notes — which are the pages developers consult when verifying they're integrating against current behavior. Typos in change logs make it harder to trust dates and content.
The fix: Add a basic build-time spellcheck or editorial pass on revision notes before publish.
22. Webhooks guide uses a different revision-number format than the rest of the platform (minor)
Problem: The Webhooks guide's revisions read 26.5.01, 26.3.01, 26.1.01 — single-digit months. Every other guide in the audit uses zero-padded 26.04.01, 26.02.01, 26.01.01. The Webhooks guide also asserts that "Message-level encryption is required for payment events" (in the 26.1.01 entry) — a hard requirement not mentioned in the Payments Developer Guide's recent revisions.
Consequence: Tooling that sorts or compares revision strings across guides ("is this guide newer than that one?") breaks on the format inconsistency: 26.10.01 would sort before 26.2.01 in a naive string compare. The MLE-required-for-payments claim, asserted only on the Webhooks page, leaves Payments-guide-only readers unaware of the requirement.
The fix: Normalize to 26.05.01 / 26.03.01 / 26.01.01. Add a corresponding "MLE is required for payment events" callout to the Payments guide intro.
23. LLM Quick Start .html → .md example link is identical in both directions (minor)
Problem: The LLM Quick Start documents the canonical URL-mangling trick agents can use: "To access a specific guide for use in your LLM, change the .html in a guide's URL to .md. For example, the Markdown version of applepay-getting-started.html can be found at applepay-getting-started.md." Both link targets are the same .md URL — the page anchored to .html never actually appears.
Consequence: The page that teaches agents the URL convention demonstrates it incorrectly. An agent following the link to confirm the convention is real sees the same URL for both, and may infer there is no .html variant.
The fix: Make the first link target applepay-getting-started.html so the demonstration matches the prose.
24. Security Keys guide renamed "Message-Level Encryption Keys" to "Token Management MLE Keys" while sibling guides still say "Message-Level Encryption" (minor)
Problem: The 25.12.01 revision: "Changed title of the Message-Level Encryption Keys section to Token Management MLE Keys." But the REST Getting Started guide, the Webhooks Implementation Guide, and the OAuth Guide all still refer to the feature as "Message-Level Encryption" / "MLE". The new "Token Management MLE Keys" name implies MLE is scoped to Token Management — when in fact the other guides say MLE applies to payment events and webhooks too.
Consequence: A developer searching for "Message-Level Encryption" in the Security Keys guide will not find a section under that name. The rename creates a false scoping signal (MLE = TMS only) that contradicts the Webhooks guide's "required for payment events" framing.
The fix: Either revert the rename, or rename consistently across all four guides. If MLE genuinely has TMS-specific and webhook-specific variants, the section headings should make that distinction explicit.
25. Payer Authentication revision says Flex Microform 3DS endpoints "were corrected" but doesn't show the values (minor)
Problem: The 26.03.01 entry: "The REST Test and Production endpoints for checking enrollment and validating 3-D Secure transactions while using Flex Microform tokens were corrected." The revision note doesn't show the corrected values inline; readers must follow two more links to find them.
Consequence: Developers who integrated against the wrong values can't tell from the change log what's now correct — they have to click through and diff for themselves. The most action-relevant fact (the new endpoint URLs) is not in the action-relevant location (the revision note).
The fix: When a revision corrects endpoint values, include the new values directly in the revision note: "…were corrected to https://api.cybersource.com/... (production) and https://apitest.cybersource.com/... (test)."
26. "VISA Platform Connect Specifications and Conditions" disclaimer embedded inline in product guides (minor)
Problem: The Credentialed Transactions guide contains a multi-clause legal disclaimer ("VISA Platform Connect: Specifications and Conditions for Resellers/Partners") that begins "The following are specifications and conditions that apply to a Reseller/Partner enabling its merchants through Cybersource for Visa Platform Connect…". This is inline legal text in the middle of a technical developer guide rather than a linked-to single-source document. Given the guide-per-processor structure, the same disclaimer is a strong single-sourcing candidate — but a verification pass across other CTV-variant guides should confirm scope before action.
Consequence: Legal text embedded inline in technical guides increases the page weight that agents and humans must page through to reach implementation content. If duplicated across CTV-variant guides (likely, given the structure), updates to the disclaimer drift between copies.
The fix: Extract the disclaimer to a single canonical page and replace inline copies with a short link ("This integration is subject to the [VISA Platform Connect terms]"). Spot-check the other CTV-variant guides for the same block before consolidation.
What they do well
The site ships a real llms.txt with explicit preferred/deprecated patterns, and a dedicated LLM Quick Start that teaches the .html → .md convention. Cybersource clearly has thought about agent consumption — the implementation has gaps (see issues 11, 12, 23), but the intent is there and is rare among payment processors.
Processor-specific variants of the major guides are an honest acknowledgment that "process a payment" looks different across CTV, Chase Paymentech, FDC Nashville, etc. — and is the right structure for a multi-acquirer platform.
The Payer Authentication guide's revision history (26.03.01) publicly admits a prior incorrect endpoint and says it was corrected — that kind of transparency is unusual.
Top 3 recommendations
Fix the entry points. The sandbox-signup page, the response-codes reference, the Unified Checkout Quick Start Step 1, and the "Accept Payments" hub tile are all broken or empty. These are the four pages a new integrator hits first. Restore them before any deeper revision work.
Resolve the JWT-vs-HTTP-Signature, SCMP-status, and SDK-version contradictions, and ship a real migration guide for the September 2026 JWT deadline. Pick one set of recommended runtimes and auth flows, then mirror them across llms.txt, the FAQ, the Getting Started guide, and the SDK page. Add a concrete migration page for the JWT changes so integrators can validate compliance before the deadline.
Treat the agent surface as a first-class contract. Publish (or remove) llms-full.txt. Replace the Afterpay "HTTP 500 under investigation" line with either a working page or a removal. Normalize revision-number formats so cross-guide tooling works. The LLM Quick Start example link should actually demonstrate the convention it teaches.
Fixed
0
Skip
0
Fail
0
Summary
No runnable public documentation code snippets were surfaced in the scraped evidence for Cybersource. The provided source material consists entirely of navigation/marketing pages, FAQ prose, revision-history bullets, processor-trigger tables (data, not code), endpoint URL listings, and partial fragments with broken placeholder substitutions. None of the 21 source URLs in the audit scope contained an executable bash/curl, JavaScript, Python, Ruby, or other-language snippet that could be run as-is.
Specifically reviewed for runnable content and found none:
llms.txt, llms-full.txt (404), hello-world/sandbox.md — directives and empty pages; no code.
hello-world/testing-guide.md, api/reference/response-codes.md — test-card and response-code tables (data only, e.g. paymentInformation.card.number = 4111111111111112); no executable snippet.
endpoints.md — lists endpoint URLs (e.g. https://apitest.cybersource.com/pts/v2/payments) without a constructed runnable request.
rest-getting-started.md, oauth.md, security-keys.md, webhooks.md, payments.md, credentials.md, payer-auth.md — guide intros, revision notes, and disclaimers; no code blocks surfaced.
unified-checkout/quick-start/uc-qsg.md — Step 1 ships with empty Test URL: \`/Production URL: ``` placeholders (no URL to execute) and test-card data only.
llm-getting-started.md — prose guidance and a self-identical example link; no executable snippet.
Because there are no executable examples to run, the verifier has nothing to PASS, FAIL, or SKIP at the snippet level. The numerous documentation defects observed (broken placeholders, past-dated decommission notices, misspellings such as paymentInformatioon and Messagel-Level Encryption and DigitCert, dead/staging links, expired test-card expirations, and contradictory guidance between llms.txt and faqs.md) are content/editorial issues that fall outside the runnable-snippet verification scope defined for this task.
The user-supplied credentials note ("[REDACTED]") did not include any API key, MID, secret, or P12 material, so even if a guide had quoted a curl/SDK snippet, authenticated execution against apitest.cybersource.com would have been SKIPPED for missing credentials.
Required credentials
None were used. No snippet was executed. Had a runnable REST example been present, it would have required:
CYBS_MERCHANT_ID (sandbox MID)
CYBS_KEY_ID (shared secret key ID) or P12 certificate path
CYBS_SECRET_KEY (shared secret) or P12 passphrase
against host apitest.cybersource.com. None were supplied.