quentin Callec

Coinbase Commerce shuts down on March 31. We teamed up with @KryptosConnect to give you the full migration stack — payments + compliance, ready before the deadline. Start creating payment links in under 1 minute → request.network/coinbase-comme… #CryptoPayments #CoinbaseCommerce

🚀 Excited to welcome @Blockscout to Request Network! They can now accept crypto & stablecoin payments globally, fully on-chain through our solution: • Direct wallet settlement • No payment providers • No custodial intermediaries This is how decentralized payments should work. @Joe_Omertali 👏 #Web3Payments #CryptoPayments #Stablecoins #CrossChain #RequestNetwork

Crypto was supposed to replace traditional payment rails, but years later, it still hasn't. I see four structural reasons why that rarely get discussed: 1. Attribution is broken. A wallet address doesn't tell you who paid or for what. The workaround is custody, which brings back the intermediaries crypto was meant to remove. 2. Pricing is distorted. PSPs bundle crypto alongside cards and price both to coexist. Crypto is overpriced. 3. Consumer fragmentation. In crypto funds are scattered across chains. Accepting crypto means managing payments across most chains and tokens. 4. Security is the payer's problem. Anyone paying in crypto is exposed to the risk without the possibility of chargeback, dispute, or reversal that traditional payment rails do. These aren't technology problems, but infrastructure problems [Continue reading]

You’re absolutely right. Stablecoins sound easy because it's public, but in practice, it's not the case. We’ve been working on a way to simplify a big part of that flow, and we’re probably one QuickBooks integration away from what you’re describing. Today: - A merchant creates an invoice via our API or manually via easyinvoice.request.network (no manual PDF-based process) - The merchant provides their receiving wallet address and payment details upfront, so there’s no back-and-forth - The payer uses a click-to-pay link with the correct data already included (no penny tests) - The payment is automatically linked to the invoice by the protocol, so there’s no need to check a block explorer or reconcile manually The offramp can still be handled separately if needed, but the crypto part of the process becomes mostly automated and familiar. End result: one on chain invoice, one matching payment, automatic confirmation, clean records, with no custody and no manual work. I’d love to get your feedback on what you think could be improved.

I would estimate as a business that it costs me an additional 2% to accept stablecoins over simple wire / ACH. For customers with stablecoin balances it's almost always easier to *send* stables: - instant test txn - instant settlement - "flight tracking" via block explorer - close to 0 fees But as a receiver, there's a much higher operating burden. Here's the workflow for accepting wires: - send invoice to customer via Quickbooks, including wire instructions in PDF - confirm wire instructions over phone (best practice, but in reality I don't do it) - customer wires; wait 1-3 days - funds hit Mercury account and are spendable immediately - Quickbooks invoice automatically confirmed paid, AR report updated And here's the stablecoin workflow: - send invoice to customer via Quickbooks - send receiving address instructions - confirm network and request test transaction - confirm test transaction, request full send - receive $USDC transaction to Coinbase - remit funds to Mercury; wait 1-3 days ("instant" withdrawal costs $100-200) - manually close Quickbooks invoice as paid - manually update AR report - manually tag transaction with customer name (otherwise all transactions are simply from Coinbase) - and all of this has to be done immediately, otherwise it gets mixed into one big Coinbase balance and it becomes impossible to untangle EOY So: - stablecoins practically take the same amount of time (1-3 days) - they require 4-5 extra manual touchpoints - they don't automatically reconcile, so someone with less context on the business would have to follow a paper trail vs. simply looking at Quickbooks I'd guess this overhead is +2% friction over traditional rails, mostly in operating labor and owner mental overhead. The way this has to improve is via a stablecoin-native neobank (of which there are many starting right now). That neobank has to be at feature parity at Mercury in order for me to switch--a tall order given Mercury is (in my opinion) a best-in-class financial front-end. I'm beyond pleased with my experience with Mercury and the product geniuses there seem to anticipate every need I have while proactively designing the interface to intercept and eliminate friction. I'm rooting for a provider built on stablecoin payment rails that can actually take advantage of the speed and transparency of stablecoins while also meeting all the boring reconciliation and accounting needs of a business.