Pouch.ph

  • Name: Pouch.ph
  • URL: https://pouch.ph/
  • Category: Lightning payments company / bitcoin payment-gateway operator / Philippines OPS-regulated merchant-and-webhook control plane
  • Tags: bitcoin-ecosystem
  • Summary: Pouch.ph belongs in companies/ because the useful question is not only what Lightning payment or invoice flow exists? but which named operator runs the Philippines-facing licensed payment shell, hosts the gateway and tip-link app, publishes the invoice-and-webhook API surface, packages merchant checkout with BTCPay-backed tooling, and frames the cross-border and merchant-adoption story users and integrators actually inherit? The old project note had already drifted into describing a regulated operator boundary rather than a neutral protocol or reusable mechanism with its own separate analytical center.
  • What it does:
    • Operates as a Philippines-based Lightning payments company focused on merchant processing, instant settlement, and cross-border payment use cases
    • Runs the hosted Pouch gateway and tip-link web application rather than only publishing a wallet or protocol spec
    • Publishes a public invoice-and-webhook API surface with /v1 endpoints for invoice creation, invoice payment, and webhook lifecycle management
    • Packages a merchant checkout surface that embeds BTCPay Server point-of-sale tooling on a Pouch-controlled domain
    • Uses a local regulatory and operating shell, including its Bangko Sentral ng Pilipinas Operator of Payment Systems positioning, as part of the trust and distribution story
    • Supports the Bitcoin Island Project as a merchant-enablement and local-adoption channel tied to the broader company footprint
  • Key claims:
    • The homepage says Pouch.ph is a Philippines-based payments company offering Lightning Network payment processing for fast, low-cost, and more connected transactions, which is the clearest first-party signal that this is an operator note rather than a protocol note
    • The same homepage says Pouch builds and runs Lightning-based payment systems for instant settlement, global interoperability, and merchant plus cross-border use cases, which makes the practical dependency an operating company shell rather than a neutral spec
    • The homepage says Pouch operates as a licensed Operator of Payment Systems under the Bangko Sentral ng Pilipinas, which makes the legal and local-operator boundary analytically important in its own right
    • The web app identifies itself as Pouch.ph | Bitcoin Payment Gateway and Pouch Tip Link, reinforcing that hosted checkout and shareable payment flows are part of the company-controlled surface
    • The public swagger.yaml defines invoice-creation, invoice-payment, and webhook-management endpoints plus transaction and participant schemas, which shows that integrators inherit a real Pouch-run application workflow rather than only Lightning primitives
    • The shop page embeds a BTCPay Server point-of-sale app on a Pouch subdomain, which is useful evidence that merchant acceptance tooling is being packaged and operated by the company rather than left as purely self-hosted merchant software
  • Whitepaper: No separate company whitepaper is the artifact that matters here. The strongest current primary materials are the homepage, gateway app surface, BTCPay-backed shop flow, public API specification, BSP OPS list, and the focused source capture in ../whitepapers/pouch-ph-primary-sources-2026-05-01.md.
  • Sources:

Internal linkages

Protocol / company boundary

  • Keep pouch-ph only as the alias preserved for legacy links.
  • Keep this note on the named operator boundary: the licensed local shell, hosted payment gateway, invoice-and-webhook lifecycle, BTCPay-backed merchant checkout packaging, and the company-shaped support/adoption perimeter around those flows.
  • That split matters because there is not an especially useful standalone Pouch.ph protocol doing separate analytical work from the regulated merchant-payments company shell.

Control surface

  • Practical authority sits in the regulated operating perimeter, hosted gateway and tip-link app, invoice creation and payment workflow, webhook lifecycle truth, merchant checkout packaging, and the local distribution/adoption shell around Pouch’s Lightning payments stack.

  • Lightning itself stays the lower-layer rail. The sharper corpus question here is who packages that rail into the specific payment, merchant, and support workflow people in this market actually inherit.

  • Read the durable risk as which named operator controls the merchant-processing and lifecycle-publication shell?, not only as which payment rail settles underneath?

  • Last reviewed: 2026-08-12 UTC