Step-by-Step Onchain USDC Invoice Settlement Verification
Learn how to verify onchain settlement of USDC invoices generated by Reclack. Step-by-step process, worked example, and code for payment confirmation.

When you collect USDC payments for SaaS or services using Reclack, payment is only complete once a blockchain transaction is confirmed. Operators and developers often need to verify that a USDC invoice has settled, both for internal systems and for customer support. This guide walks through checking onchain settlement for a Reclack-generated invoice, with a worked example and practical code.
What Defines Settlement for a Reclack USDC Invoice
A Reclack invoice specifies a payment amount, recipient address, and the chain (Base, Ethereum, or Polygon). Settlement occurs when a USDC transfer matching the invoice terms is confirmed on the relevant chain. There is no chargeback. Once the transaction is mined and meets your confirmation policy, the payment is final.
Key Data from the Invoice
To verify settlement, you need:
- The invoice USDC amount (e.g., 200 USDC)
- The merchant’s settlement address (e.g.,
0xMerchant) - The chain (e.g., Base)
- The USDC contract address on that chain
Reclack surfaces these in the hosted checkout, API, and invoice metadata. You do not need a Reclack private key or access to the merchant wallet.
Look Up the Expected USDC Transfer
The goal is to find a confirmed USDC transfer from the customer’s wallet to the merchant’s address, matching the invoice amount. This can be done using a block explorer or programmatically.
Using a Block Explorer
On Base, use https://basescan.org. On Ethereum, https://etherscan.io. On Polygon, https://polygonscan.com.
- Search for the merchant’s address.
- Go to the “ERC-20 Token Txns” tab.
- Filter for the USDC contract address on that chain.
- Find a transaction where:
Fromis the customer’s addressTois the merchant’s addressTokenis USDC- The amount matches the invoice
- The timestamp is after invoice creation (to avoid matching past payments)
Programmatic Verification Example
You can automate this with any Web3 client. Here’s a Node.js example using ethers.js. This fetches USDC transfers to the merchant’s address and checks for a matching payment.
const { ethers } = require("ethers");
// Set up provider for Base
const provider = new ethers.JsonRpcProvider('https://mainnet.base.org');
// USDC contract on Base
const USDC_ADDRESS = "0x..."; // Use actual USDC contract address
const merchant = "0xMerchant";
const customer = "0xCustomer";
const amount = ethers.parseUnits("200", 6); // 200 USDC, 6 decimals
const fromBlock = 5000000; // Block number at invoice creation
// ERC-20 Transfer event signature
const TRANSFER_EVENT = "event Transfer(address indexed from, address indexed to, uint256 value)";
async function findUSDCInvoicePayment() {
const usdc = new ethers.Contract(USDC_ADDRESS, [TRANSFER_EVENT], provider);
const filter = usdc.filters.Transfer(customer, merchant);
filter.fromBlock = fromBlock;
filter.toBlock = "latest";
const logs = await provider.getLogs(filter);
for (const log of logs) {
const parsed = usdc.interface.parseLog(log);
if (parsed.args.value === amount) {
const tx = await provider.getTransaction(log.transactionHash);
const receipt = await provider.getTransactionReceipt(log.transactionHash);
if (receipt && receipt.status === 1) {
console.log(`Found confirmed payment: ${log.transactionHash}`);
return log.transactionHash;
}
}
}
console.log("No matching payment found.");
}
findUSDCInvoicePayment();
This script checks for a USDC transfer from the customer to the merchant for exactly 200 USDC, after a specified block. It prints the transaction hash if found and confirmed.
Handling Multiple Payments and Edge Cases
Sometimes, a customer may try to pay the same invoice more than once, or send the wrong amount. If you find more than one matching transfer, use the earliest one that meets the invoice criteria and is confirmed. If the amount is less than the invoice, treat it as unpaid. If greater, decide on your policy: you may treat it as settled and refund excess, or reject it as invalid.
Invoices are not linked to customer addresses by the protocol. If a customer pays from a different wallet, you need to decide whether to accept that as fulfilling the invoice. Reclack surfaces the detected payer address, but you control the mapping in your application.
What to Do When No Payment Is Found
If your search returns no matching transfer, the invoice is not yet settled. Common reasons include:
- Customer paid to the wrong address
- Payment was made with the wrong token
- Payment is pending and not yet mined
- Customer never initiated the payment
Reclack does not hold funds and cannot reverse or correct such issues. Only a new, properly formatted transaction on the correct chain and contract can settle the invoice.
Worked Example: Verifying a 200 USDC Invoice on Base
Suppose you issued an invoice for 200 USDC to 0xMerchant on Base. The invoice was created at block 5,000,000. The customer’s address is 0xCustomer. You expect a USDC transfer on Base after block 5,000,000.
- Merchant:
0xMerchant - Customer:
0xCustomer - USDC contract on Base:
0xA0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 - Amount: 200 USDC (200,000,000 in 6 decimals)
- Creation block: 5,000,000
On https://basescan.org, search for 0xMerchant, view “ERC-20 Token Txns”, filter for USDC. Look for a transfer from 0xCustomer to 0xMerchant for 200 USDC, after the invoice block. Confirm the transaction status is “Success”. This payment is now settled: you can mark the invoice as paid.
If you automate this check, you would use the code example above, filling in the addresses, amount, and block number. If the customer later asks for a receipt, you can provide the transaction hash as proof of payment.
Confirmations: When Is Payment Final?
Onchain settlement is final once the transaction is confirmed. For most SaaS use cases, 1 confirmation is sufficient on Base and Polygon. You may require more on Ethereum. Reclack records the transaction hash and confirmation count. Once you see the expected transfer in a confirmed block, the payment is final. There is no onchain reversal.
How Reclack Surfaces Onchain Settlement
We build Reclack so every invoice, whether one-time or recurring, is tied to an onchain payment. Our API and dashboard surface the invoice amount, payer, recipient, chain, transaction hash, and confirmation status. You can always audit payments onchain without relying on us. For more on how Reclack handles settlement, visit reclack.com.

