Cowrie Research

inxy-payments

4 min read

INXY Payments

  • Name: INXY Payments
  • URL: https://www.inxy.io/
  • Category: crypto payment gateway operator / stablecoin-and-fintech API company / hosted checkout-and-webhook workflow boundary
  • Tags: ethereum-ecosystem
  • Summary: INXY Payments belongs in companies/ because the useful question is not only what does the checkout SDK do? but which named operator hosts the payment page, issues merchant credentials, defines supported asset and network coverage, signs webhook-style lifecycle events, and keeps whatever settlement and request-authentication policy sits behind that stack? The old project note had already drifted into describing a company-run merchant workflow shell rather than a neutral protocol or reusable payment primitive.
  • What it does:
    • Operates a hosted crypto-payment gateway for businesses that want redirect-based checkout instead of building their own settlement and payment-page flow
    • Issues merchant-facing SDK and API workflow for creating multi-currency payment sessions and redirecting customers to INXY-hosted payment pages
    • Publishes signed webhook lifecycle events around initialization, confirmation waiting, receipt, and partial-payment handling that downstream merchants may treat as operational payment truth
    • Exposes a separate RSA/PEM signature SDK, suggesting that authenticated backend request flow and request-signing policy sit with the named operator rather than only in a public checkout recipe
    • Markets a broader fintech and stablecoin API posture in addition to merchant checkout, implying one company-run shell for payments, payouts, and conversion-oriented integration rather than a single narrow widget
    • Frames itself through official-site titles and snippets as a business-facing crypto-payments platform with a regulated or compliance-shaped operating shell, even though the rendered site capture in the earlier source pass was incomplete
  • Key claims:
    • The homepage title is Crypto Payment Gateway for Business — INXY Payments, which is already operator-shell language rather than protocol language
    • The fintech page title is Fintech Crypto API & Stablecoin Infrastructure | INXY Payments, which suggests INXY wants to be treated as broader payment-and-settlement infrastructure rather than only a hosted checkout page
    • The earlier primary-source capture notes that official-site snippets tied to INXY’s homepage describe it as an EU-authorized and Canada-registered platform for accepting, sending, and managing cryptocurrencies; treat that as company positioning until a future browser-based pass re-validates the rendered legal copy directly
    • The official PHP merchant-sdk README shows the real merchant flow plainly: create a MultiCurrencySessionRequest, choose supported assets, provide redirect URLs, and send the customer to an INXY-hosted payment page returned by createMultiCurrencySession
    • That same README documents signed webhook handling through X-INXY-Payments-Signature plus concrete lifecycle events such as PaymentsInit, PaymentsWaitingConfirmations, and PaymentsReceived, including partial-payment states, which makes INXY’s company-run callback surface part of the live merchant workflow
    • The signature-sdk-js package creates Base64 signatures and timestamps from payloads plus RSA/PEM keys, which is strong evidence that authenticated backend requests and signature semantics are part of the operator boundary, not only a frontend checkout convenience
    • The supported examples in the SDK include USDT on Ethereum and BNB Smart Chain plus BTC, ETH, DOGE, and USDC, which shows chain and asset coverage is an INXY-defined product and policy surface merchants inherit rather than a neutral interoperability standard
  • Whitepaper: No separate company whitepaper is the point here. The clearest primary materials are the official homepage and fintech page titles/snippets plus INXY’s first-party merchant and signature SDK repositories, captured in ../whitepapers/inxy-payments-primary-sources-2026-05-02.md.
  • Sources:

Internal linkages

  • Project-layer alias: inxy-payments.
  • Useful adjacent operator-shell comparisons: coinflow, copperx, and dodo-payments.
  • Reusable lens: when hosted payment pages, credential issuance, signature validation, and webhook-backed lifecycle truth all sit with one vendor, the company boundary usually matters more than the API recipe.

Protocol / company boundary

  • Keep inxy-payments only as the alias preserved for legacy links.
  • Keep this note on INXY Payments as the named operator that hosts the payment page, issues merchant access, defines supported asset coverage, signs or authenticates callbacks and backend requests, and packages the broader fintech / stablecoin workflow shell.
  • That split matters because there is no especially useful standalone INXY protocol layer doing separate analytical work from the company-run merchant and API workflow boundary.

Control surface

  • Practical authority sits in merchant admission, API and SDK credential flow, hosted redirect behavior, supported asset and network coverage, signed webhook publication, partial-payment handling, settlement workflow, and whatever authenticated backend methods INXY exposes through its request-signing tooling.

  • Crypto gateway is the important shape here, not open payment rail. Merchants can inherit INXY as workflow truth for session state, payment confirmation, retry logic, and backend authentication even if the underlying settlement assets are standard cryptocurrencies.

  • Read INXY Payments as a company-operated checkout, webhook, and settlement-control shell rather than a neutral protocol primitive.

  • Last reviewed: 2026-08-13 UTC

Graph View

Backlinks