r/ethdev • u/Cold_Adhesiveness810 • 15d ago
My Project Architecture breakdown: How we solved the "No ETH for gas" problem for WooCommerce crypto subscriptions on Base
Hey everyone,
I run a small US software studio, and we do a lot of platform engineering for merchants. Everyone wants to accept crypto, but we kept running into the same UX nightmare: buyers want to pay in USDC, but their transactions fail because they don't have native ETH in their wallets to cover the gas.
Plus, most existing WooCommerce plugins force the merchant to use a centralized gateway, which defeats the purpose.
We spent the last few weeks engineering a workaround natively on the Base network, and I wanted to share the architecture in case anyone else is building merchant tools.
How we structured it: Instead of making the buyer pay gas, we built a relayer system.
- The buyer signs a gasless message (EIP-712) approving the USDC transfer.
- Our relayer submits the transaction to the network and pays the gas in ETH.
- The smart contract executes the transfer, settling the USDC directly into the merchant's wallet, and reimburses the relayer's gas cost by taking a tiny fraction of the USDC.
We also built this to support onchain recurring subscriptions so buyers don't have to manually approve transfers every month.
We packaged the whole thing into an open-source WooCommerce plugin and a few SDKs (PHP, JS, Laravel) called P2Flux.
If anyone is working on relayer mechanics on Base or wants to inspect how we handled the recurring smart contracts, you can tear apart our code here:https://github.com/P2Flux
Curious how others are handling the stablecoin gas friction for non-crypto-native buyers?
4
u/PlayfulGovernment325 15d ago
this is extremely standard. gas abstraction has existed for a long time. glad you figured it out tho!