Why We Built a Multi-Protocol Architecture
How soft.house achieves 69.5% code sharing between Google AP2 and OpenAI ACP while maintaining protocol-specific security guarantees.
When we started building soft.house, we faced a fundamental architectural decision: should we pick a single AI commerce protocol, or support multiple protocols simultaneously?
The Problem
The AI commerce landscape is fragmenting. Google has AP2 (Agent Payments Protocol), OpenAI and Stripe have ACP (Agentic Commerce Protocol), and Visa is developing TAP (Trust & Agent Protocol). Each serves a different purpose in the commerce stack.
Choosing just one would lock developers into a single ecosystem. We decided to support them all.
The Solution: Protocol Abstraction
We built a unified mandate service that shares 69.5% of code between AP2 and ACP:
| Component | Sharing | How |
|---|---|---|
| Cryptographic services | 100% | Shared ECDSA, HMAC infrastructure |
| Nonce validation | 100% | KV-based replay prevention |
| Mandate management | 70% | Unified schema with protocol_metadata JSONB |
| Protocol detection | 100% | Automatic header-based routing |
Protocol-specific logic (about 15% per protocol) lives in dedicated directories.
The Three-Layer Model
Rather than treating protocols as alternatives, we organize them as complementary layers:
- Identity (TAP) — Is the agent legitimate?
- Authorization (AP2) — Did the user approve?
- Execution (ACP) — Process the payment
This model prevents the common mistake of trying to replace one protocol with another.
Results
- 1,180 lines saved versus naive separate implementations
- 100% test pass rate across both protocol suites
- Sub-200ms response times on all protocol endpoints
- Single database schema serving both protocols
What’s Next
We’re working on TAP integration for the identity layer, and expanding our A2A bridge for agent-to-agent communication. Stay tuned.