Frequently asked questions

PaychainX is a programmable payment orchestration gateway. Unlike a traditional gateway that forwards a transaction to one processor, PaychainX normalizes every payment, decides how to route it, runs it through a uniform processor adapter, and seals the result in an independent cryptographic proof. In short: most gateways move transactions, PaychainX governs, abstracts, orchestrates, and proves them.

The core engine is live. PaychainX itself is the orchestration and post-quantum layer we built. It processes real authorizations through a connection to CyberSource, is in pilot with the Propelr partner platform, and is partnered with Zero Hash for stablecoin settlement, and every payment emits an independent proof. To be precise about stage: it is live in an integration and acceptance context. Production-scale volume, full card-network and PCI certifications, and long-run history are still in progress. We label live versus roadmap throughout the site rather than blur them.

Three ways. First, processor abstraction: merchants integrate once, and processors become interchangeable behind a single adapter interface. Second, merchant-controlled routing rather than processor-defined behaviour. Third, a per-transaction tamper-evident proof, so the audit trail is generated live, not reconstructed after the fact.

One payment intent can be routed to more than one settlement rail behind a single integration. Today the card rail is live through our CyberSource connection. The stablecoin B2C rail, with Zero Hash as the settlement provider, is nearing production at roughly 90 percent. The stablecoin B2B rail (business-to-business flows, also via Zero Hash) is in design and scoping. The architecture is built so adding a rail does not change the merchant integration, the canonical request and response stay the same.

Each payment commits to a proof hash computed as SHA-256(canonical(payload)), where canonical JSON sorts keys recursively so the bytes are deterministic. Receipts are chained, each carrying the previous hash, so altering any field breaks every hash after it. The proof is independent of the processor response, which is what makes it an audit lineage rather than a log.

Yes, that is the point. The Proof page and the Post-Quantum page recompute the hashes live in your own browser with the Web Crypto API. A Visa or bank reviewer can confirm the math independently, and tampering with a value makes verification fail in front of them.

Card credentials are tokenized. Stored-credential transactions use a card-on-file token reference, so the raw PAN stays out of the application. This is also what shrinks PCI scope for merchants who integrate.

API-key authentication is enforced at the gateway, and invalid credentials are rejected with HTTP 401. Every POST /v1/payments/* requires an Idempotency-Key, and the request body is fingerprinted with SHA-256(canonicalize(body)) so a retry can never create a second charge. Webhooks are HMAC-signed with automatic retries and delivery tracking.

Tokenization and the security controls above are built in, which reduces PCI scope. Formal PCI-DSS certification is on the roadmap, not claimed as complete. We do not market certifications before they are real.

Because of harvest now, decrypt later: an adversary can capture encrypted data today and break it once a large quantum computer exists. The June 22, 2026 Executive Order directs the federal transition to NIST post-quantum standards, with key establishment by December 31, 2030 and digital signatures by December 31, 2031, plus a FAR rule requiring contractors to comply by 2030. Audit evidence that banks rely on has to stay verifiable across that change.

Live today: every payment gets a SHA-256 audit proof, and the gateway builds a hybrid PQ envelope that computes a SHA-512 pq_hash and an HMAC-SHA512 pq_signature in hybrid-ready mode. Roadmap: replacing the in-process fallback with a vetted ML-DSA provider through the PQ sidecar. The envelope already reserves the pq_sig: ml-dsa and pq_kem: ml-kem slots, so the migration is structural, not a rewrite.

NIST FIPS 203 (ML-KEM) for key establishment and FIPS 204 (ML-DSA) for digital signatures, the same standards named in the federal mandate. See the References page for the primary sources.

No. The envelope shape stays constant across phases (off, hybrid-ready, hybrid-enforced), so merchants integrate once and the cryptographic guarantees strengthen underneath them without a breaking cutover.

Integrate once against the gateway API. Each rail implements the same adapter contract: sale, capture, void, refund, with normalized inputs and a normalized result. Supply an Idempotency-Key on payment calls. The Platform page shows the real interface and router.

The router accepts sandbox_card, cybersource_transient_token, and bank_token sources.

Events fan out to multiple endpoints with automatic retries (up to five attempts), per-endpoint delivery status, and failure tracking, so a merchant endpoint never silently misses a payment update. Each event is HMAC-signed so the receiver can verify authenticity.

Yes. The same gateway serves online (channel: api) and card-present terminals such as the PAX A920 Pro, carrying terminal and device identifiers through the ledger for unified reporting.

No. Every page here runs entirely in your browser with no API key and makes no call to the production gateway. The checkout response, receipts, proof verifier, and PQ envelope are all computed locally. That is why it is safe to host publicly.

They reflect a reference and acceptance environment and are illustrative of capability, not realized commercial volume. Amounts shown in demos are in minor units (cents) and use non-routable test data.

PaychainX is built on a clean, transferable IP position: a dependency license audit found no GPL, AGPL, or LGPL copyleft components, and the codebase has an auditable GitHub history with reproducible builds. The platform can be licensed, white-labeled, or acquired. Commercial details are shared under NDA.

Qualified parties can receive a live demonstration and time-boxed API test access under NDA, along with a diligence package. Contact info@paychainx.com or visit paychainx.com.