The earlier version of this page described a proposed StateSet Commerce Network integration
using SDKs and network hosts that are not established by the current documentation contracts.
It is not a runnable transfer quickstart. The previous install, faucet, and RPC commands have
been removed so they cannot be mistaken for a supported deployment path.
Do not send funds using an address or network identifier copied from a documentation example.
Obtain the deployed network, supported transfer protocol, contract identifiers, and test
environment from the integration owner before implementing a payment.
Choose the operation you need
A local payment record is not proof of a blockchain transfer. Keep the provider or network
transaction identifier separately, and verify settlement using the system that moved the funds.
Required integration evidence
Before writing a transfer adapter, record the source and destination environments, supported
assets, address format, protocol version, authorization mechanism, fees, and completion signal.
The owner must also provide a test procedure for rejected, delayed, and duplicate submissions.
Do not infer any of these from the Commerce HTTP host: it documents commerce records and is
not a substitute for a chain RPC or a transfer protocol contract.
Acceptance criteria
Use an isolated test environment with explicit spending limits. Record the submitted request,
transaction ID, destination observation, and final state. Exercise a lost response before enabling
retries: reconcile the first attempt instead of submitting a second transfer blindly.
Continue with payment verification for local records or the
API directory for service-specific integration contracts. 
