proceed_payment_and_settlement_detail_infoLABSCO SUMMARY
A whole payment network, testnet-first.
The interesting structure is that payment is not one agent but five with separate jobs, so signing, settlement and payee confirmation are distinct steps with their own state rather than one opaque call. What that costs you is scope: this is a repository you deploy with a Postgres behind it, and today it runs on testnets, so treat it as a working reference implementation of agent-to-agent payment rather than something to point at production funds.
What it is
An implementation of DePA (Decentralized Payment Agent): a coordinator plus five specialised sub-agents — payer, settlement, payee, order and allowance — that handle order creation, EIP-712 signing, balance checks, on-chain execution and transaction monitoring. It speaks both Google's A2A protocol and MCP, so it can be reached by another agent or by an MCP client.
What you get
- A payment and settlement flow exposed as one MCP tool over SSE —
proceed_payment_and_settlement_detail_info - Five specialised sub-agents behind that surface:
payer_agentfor order creation, EIP-712 signature generation and wallet balance checks;settlement_agentfor confirming details, executing on-chain and monitoring status;payee_agentfor receiving settlement notifications and confirming completion;order_agentfor intent recognition and routing;allowance_agentfor multi-chain token authorization queries - Both custodial and non-custodial modes — the backend manages wallets, or the user keeps the private keys
- EIP-712 typed data signing on EVM chains with permit support for USDC and DAI, and Ed25519 signing on Solana
- An A2A server exposing agent capabilities through an
AgentCardon port 10000, alongside the MCP server on port 8015 - Full transaction lifecycle tracking — intents, audit events, settlement batches and settlement details persisted in PostgreSQL
Requirements
This is a stack you run, not a package you install: Python 3.13 or higher with uv, Git, and PostgreSQL with SQLModel for persistence. The host agent uses gemini-2.0-flash-lite as its coordinator model. Chain support is testnet-only today — Ethereum Sepolia, Base Sepolia, Polygon Amoy and BNB Chain Testnet on the EVM side, Devnet and Testnet on Solana — with USDC (Version 2), DAI (Version 1) and SPL tokens, and MetaMask, Coinbase Wallet and Phantom as the integrated wallets. The project's own security note says test-environment private keys are for development only and production needs mainnet configuration and proper key management. Licensed Apache 2.0.
Setup effort
Build from source — git clone https://github.com/Zen7-Labs/Zen7-Payment-Agent.git
USE CASES
Letting one agent pay another for a service
Drive the payment and settlement flow from an MCP client and let the order agent recognise the intent and route it to the payer and settlement agents.
Checking what a wallet is already authorised to spend
Query the allowance agent for token authorizations across the configured chains before initiating a transfer.
Choosing who holds the keys
Run the custodial handler when you want the backend to manage wallets, or the non-custodial one when the user must keep the private key.
Auditing a completed payment
Read the intent record, audit events, settlement batch and settlement detail rows in Postgres for the full lifecycle of one transaction.
1 tool
Listed in project docs. Your client may show a different list.
BEFORE YOU INSTALL
What to know first
Tools you get
1 tool named in the project's documentation.
Requires
- GOOGLE_API_KEY in your environment
- PAYER_PRIVATE_KEY in your environment
- SETTLEMENT_PRIVATE_KEY in your environment
INSTALLATION
Connect your client
This one is built from source rather than installed with a single command.
Server setup
git clone https://github.com/Zen7-Labs/Zen7-Payment-Agent.git
cd Zen7-Payment-Agent
uv venv
source .venv/bin/activate
uv syncRename .env.example to .env
./run.sh start mcp --host 127.0.0.1 --port 8015