GigaWallet: the payments backend
In lesson 7 you built payment detection by hand. GigaWallet is the Dogecoin Foundation's official version of that machine: a Go service that sits on top of your Dogecoin Core node and hands your application a clean REST API for accounts, invoices, and payment events – custody stays yours, plumbing stops being your problem.
What it gives you
GigaWallet occupies the sweet spot between raw RPC and a third-party processor:
- Accounts & addresses: create an account per customer or store; GigaWallet manages address generation against the node.
- Invoices: "invoice for 100 DOGE" as a first-class API object with its own address and status – the pattern from lesson 7, productized.
- Payment events: instead of your poll loop, GigaWallet watches the chain and notifies your app when invoices are paid or funds arrive, with confirmation tracking built in.
- Sends: outbound payments through the same API, so your app code never touches RPC directly.
Because it runs on your server against your node, no third party holds funds, takes a percentage, or can turn your integration off – the trade is that you operate it, like any other backend service.
The deployment shape
[your app / store]
| REST + events (localhost or private network)
[GigaWallet] one Go binary + config
| JSON-RPC
[Dogecoin Core] your node, txindex on, RPC localhost-only
|
the network
All three pieces commonly live on one box for small operations. The official gigawallet.dogecoin.org docs cover configuration and the current API surface; the repository is the source of truth. (We deliberately don't reproduce endpoint signatures here – docs age, links don't.)
Real-world proof: WooCommerce
The clearest sign of what GigaWallet is for: the GigaWallet WooCommerce gateway turns any WordPress store into a DOGE-accepting shop backed by your own node. If your goal is "accept Dogecoin in my existing store", that path may mean writing no code at all – install the plugin, point it at your GigaWallet, done.
Honest status check
Our directory labels projects by observed activity, and GigaWallet's repo has been quieter lately than Libdogecoin's – it's a working, complete service rather than a fast-moving one. What that means practically: expect stable concepts and working code, test your integration on testnet like everything else, and check the repo's issues before betting a launch on a specific edge case. That's the same diligence you'd apply to any dependency – we just say it out loud here.
Choosing between your three payment paths
| Path | You operate | Custody | Best for |
|---|---|---|---|
| Raw RPC (lesson 7) | Node + your own watcher code | Yours | Bots, custom flows, learning, full control |
| GigaWallet | Node + one service | Yours | Stores and apps that want a payments API without writing one |
| Processor (BitPay etc.) | Nothing | Theirs | Fastest integration; fiat settlement; you accept the middleman |
The full decision framework – including the security work each path implies – is the subject of the final lesson.
Key takeaways
- GigaWallet = the Foundation's self-hosted payments backend: accounts, invoices, events over REST.
- It replaces your hand-rolled watcher while keeping custody and control with you.
- One binary next to your node; WooCommerce integration exists for no-code storefronts.
- Check current docs and repo activity before launch – and test on testnet, always.