Digital Shield Pay: a non-custodial USDT checkout for merchants

What the project actually is

Digital Shield Pay is a non-custodial on-chain payment integration tool for developers and merchants. It creates orders, matches on-chain transactions, and synchronises payment status, and the README says to confirm that your business may lawfully accept the relevant digital assets in every jurisdiction where it operates before using it.

That last clause is not boilerplate. It is the boundary condition of the whole product, and it appears at the top of the What Is section rather than in a compliance appendix.

The repository layout makes the shape of the project clear. The top level is .gitignore, a Demo/ directory, two READMEs in English and Simplified Chinese, an SDK/ directory, a back-end/ directory and a src/ directory. The primary language is listed as Shell, and the src/ tree holds the documentation assets, with the header logo and the network icons under src/why-ds-pay/network-icons/ and the flow diagrams under src/how-it-works/ and src/quick-integration/. So the repository is documentation, integration guides and runnable demos, not the gateway implementation itself.

That is the single most important fact for an adopter. You are integrating with a hosted service whose API is documented here, and the code you will write against is the merchant side of that API. The homepage is mcashier.ds.pro, the official site is ds.pro, and the last push to the main branch was on 2026-09-21 with no GitHub releases.

Non-custodial means the funds never touch the provider

The central claim of the product is the fund flow, and the README states it precisely: funds move directly from the payer's wallet to the merchant's receiving address, and DS-Pay never takes possession of funds and does not participate in custody, transfers or settlement.

That is a meaningful architectural statement for a payment provider, because most do take custody, at least transiently, and that is what makes them a regulated counterparty. A non-custodial gateway is a matching and notification layer: it knows an order exists, it watches an address, it decides which incoming transaction pays which order, and it tells you. The money path is a wallet-to-wallet transfer that the provider does not touch.

The rest of the feature list follows from that division of labour. Order-level transaction matching links on-chain payments to merchant orders, with status records for merchant-initiated post-payment handling. Real-time on-chain monitoring means the gateway continuously watches target network transaction events, synchronises the on-chain result and updates order status automatically. Standardised system integration means HTTP APIs and asynchronous callback notifications, so it plugs into an existing business system rather than replacing it.

The fee position is stated with a caveat attached, which is the honest way to write it: DS-Pay currently charges no platform transaction service fee, while blockchain network, wallet and third-party fees are excluded, and fee policies may change, so refer to the latest official terms.

The compliance section adds the restrictions. DS-Pay must not be used for fraud, money laundering, terrorist financing, illegal gambling, sanctions evasion, infringement, unlawful goods or any other illegal activity, merchants are responsible for their own products, services, marketing, taxes and consumer-protection practices, and the provider gives no legal, tax, investment or financial advice and makes no guarantee about digital-asset value, availability or transaction finality.

Nine networks, two tokens, and the eighteen combinations

The network table is the clearest statement of scope, and the supported set is USDT and USDC on each of nine chains.

Ethereum, BNB Chain, Polygon, Arbitrum, Base, Solana, SUI, TRON and Polkadot AssetHub each list USDT and USDC as the supported tokens. The README says more networks and tokens are coming soon, and the topics attached to the repository cover crypto-payment-sdk, multi-chain, multi-chain-wallet, multi-chain-wallet-api, payment-gateway and web3.

The configuration step makes the size of that surface concrete: the receiving address configuration supports 9 blockchain networks and 2 settlement tokens, providing 18 receiving combinations. So a merchant who wants to be paid in USDC on SUI is a different configuration from one who wants USDT on Ethereum, because the flow has the customer select a network and token at checkout.

That division is worth understanding. The merchant configures the addresses it will accept; the customer chooses which of those to pay with at the Pay Now step. So the merchant's risk surface is the set of addresses it holds, and the customer's choice is a checkout-time decision rather than a merchant-side switch.

The intended use section is broad but bounded: lawful software services, digital content, e-commerce and developer tools, subject to local law and platform policies, and the project states it does not endorse the legality, compliance or suitability of any particular industry or business model.

The integration sequence, and why the redirect is not proof

The Quick Integration section is the operational part of the document, and it is a seven step sequence.

You log in to the merchant dashboard, registering and signing in by scanning a QR code with WalletConnect. You configure the receiving address. You create a Payment Key with one click and rotate it as needed to secure API access. You optionally configure a callback URL to receive real-time order status notifications and connect them to your business system.

Then the server-side part. You sign and call POST /dspay/public/order/create, and you receive an orderNo and a checkoutUrl. You redirect the customer to that checkoutUrl, where they select a network and token and confirm Pay Now.

And then the part that is stated most firmly in the whole README: confirm the result by verifying webhooks and using POST /dspay/public/order/query as the authoritative fallback, because a browser redirect is never proof of payment.

That last sentence is a security instruction, and it should be the design centre of any integration built on this. A customer can close the tab, a proxy can return a success page, and a user can simply close the page. The only facts about payment are the ones the provider observed on chain and reported through the webhook or the query endpoint. The order query is named as the authoritative fallback, which means the safe implementation treats the webhook as the fast path and the query as the thing that actually decides.

The Payment Key with rotation deserves a note as well. It is the credential that secures API access, and being able to rotate it means the credential has an expected life shorter than the account, which is a good default for anything that can move money.

The documentation for the details is the SDK Integration Guide at SDK/SDK.en-US.md.

The demos are the integration reference, and the baselines are specific

The Demo directory ships a mock merchant demo that lets you experience the complete DS-Pay payment integration flow without moving real funds, and it covers four integration targets.

There is a Java back end guide, a Node.js back end guide, a PHP back end guide and a front end guide, and the README points to the Demo directory for more demos. So the same flow is expressed three times on the server, once in each of the three most common back end stacks, which makes it easy to copy the shape rather than reverse engineer it.

The demo baselines are stated, which is unusual and useful. Node.js 18.20.8 with npm 10.8.2, JDK 11 and later, PHP 5.6 and later, and a modern browser supporting crypto.randomUUID(). The README also says only one Node.js version is needed, which is a small but practical point, and it points at the Tested runtimes section of the Demo README for the exact validated versions and dependency details.

Two things follow from the fact that the front end demo needs crypto.randomUUID(). That method is only available in a secure context, so the demo will not run from a plain file URL or over plain HTTP, and the front end guide has to be served properly rather than opened directly. For a payment flow that is the right constraint to have, since the order creation and the checkout both need to be on a real origin.

The Demo directory has its own README in English and Simplified Chinese, and the top level also carries a back-end/ directory, so the examples exist both as guidance under Demo/ and as something closer to runnable code under back-end/.

Editorial conclusion

Adopt Digital Shield Pay if you need USDT and USDC checkout that moves funds directly from the payer to your receiving address and you want the matching logic handled for you, because the non-custodial design means you never hold the funds and the order-to-transaction matching is the part that is genuinely hard to build. Do not adopt it as a self-hosted component, because the repository holds the integration guide, SDK documentation and demo back ends rather than the gateway server, so you are integrating with a hosted service. Before you build, read the SDK Integration Guide for the signing details, treat the webhook as the primary signal and the order query as the fallback rather than the browser redirect, and confirm that accepting these assets is lawful in every jurisdiction where you operate.

Frequently asked questions

Official sources

1. DigitalShieldOfficial/USDT-Payment-Gateway on GitHub
2. Issues
3. Project website
4. README