Merchant examples

Download working Pay by Paybyte examples.

These packages are reference merchant integrations for PBE Mainnet and are meant to be copied onto a compatible PBE web node and adapted. They use the Paybyte Ice interface, keep authoritative order values and credentials out of browser control, and include explicit setup files instead of silently changing your merchant database.

Examples, not hidden infrastructureThe downloadable folders are ordinary PHP/JavaScript examples. Merchant payment values are created server-side. The Golden Sword example additionally uses the Commerce webhook credentials already configured on the merchant-controlled PBE node.

Paybyte Coffee Mug secure checkoutReal 50 PBE wallet handoff + server-owned order tuple + server-side exact payment polling. Includes README.txt and a no-op database.sql because this session-based checkout example requires no merchant tables. Golden Sword webhook fulfilmentReal 25 PBE payment + signed server-to-server webhook + idempotent MySQL inventory grant. Includes README.txt and the required database.sql.

Coffee Mug secure checkout

Use this example when you want the smallest server-authoritative checkout flow. PHP chooses the merchant recipient, amount, confirmation policy and unique reference from demo-config.php, creates the PBE-PAY request server-side, stores the authoritative tuple in the PHP session, and polls the PBE node itself. Browser JavaScript only displays the returned order and payment state, so changing DevTools cannot change what the merchant endpoint considers paid.

Included file	Purpose
README.txt	Installation, configuration, security model and expected checkout flow.
demo-config.php	Server-side product, amount, recipient, node and wallet settings. No secrets.
api.php	CSRF-protected merchant endpoint for creating orders and returning server-verified payment state.
lib.php	Creates the PBE-PAY request, stores the authoritative tuple and polls the exact payment server-side.
assets/app.js	Renders server state and opens the server-created wallet handoff. It never supplies authoritative merchant payment values.

What DevTools can and cannot doA customer can always alter what their own browser displays or change the wallet link they personally open. That does not change the recipient, amount or reference stored by the merchant PHP session, and it cannot make api.php report a different payment as confirmed.

Session checkout vs. production ordersThe Coffee Mug example intentionally avoids a database so the security boundary is easy to see. A production store should persist orders in its own merchant database. Use signed Commerce webhooks when payment confirmation should trigger automatic fulfilment without browser polling.

Golden Sword webhook fulfilment

Use this example when a merchant application must automatically grant something after payment. The customer browser never decides fulfilment. A signed PBE webhook updates merchant-owned MySQL state and grants the fake item exactly once.

Included file	Purpose
README.txt	Manual installation, webhook configuration, security notes and cleanup.
database.sql	Three disposable merchant demo tables. Import manually before running the example.
demo-config.php	Public demo values such as recipient, amount, node URL and callback URL. No secrets.
webhook.php	HMAC-authenticated webhook receiver and fulfilment entry point.

Database changes are manualThe Golden Sword example checks that its tables exist and stops with a setup message if they do not. It never issues CREATE TABLE from a browser request.

Where credentials live

The Coffee Mug example requires no database password, manageToken or signingSecret. Its authoritative checkout settings live server-side in demo-config.php. The Golden Sword webhook example deliberately does not ship database passwords, manageToken or signingSecret; when installed under a PBE web node it reads those secrets from the node's existing config/config.php.

Server docs vs. standalone nodes

The Merchant portal and these hosted downloads are part of the Paybyte.org/server distribution. Standalone node packages can remain focused on node operation and link back to Paybyte.org for merchant documentation and example archives. The payment protocol itself does not depend on Paybyte.org.