MyZubster Gateway

🌍 Understand MyZubster in your language: Global multilingual guide — English, Italiano, Español, Français, Deutsch, Português, 中文, 日本語, 한국어, العربية, हिन्दी, Русский, Türkçe, Bahasa Indonesia, Polski, Українська, বাংলা, اردو, فارسی, Kiswahili.

MyZubster connects real-world observations, verifiable evidence, collaborative bounties and platform rewards. MYZ is currently an internal reward/accounting ledger; external XMR/token/blockchain settlement is separate and independently verified.

Backend integration boundary for the MyZubster ecosystem, including API, order, webhook, registry and payment/settlement-related components.

MVP / active validation. The repository contains working backend components and automated tests. Payment, settlement and external-provider integrations are environment-dependent until the corresponding integration and independent-verification checks are green.

The Gateway is not the canonical authority for declaring an external payment final.

MyZubster core
      |
      v
Gateway / adapters
      |
      v
payment/treasury provider
      |
      v
independent verifier
      |
      v
CONFIRMED / PAID

See:

• Ecosystem Architecture
• Canonical Bounty System
• BOUNTIES.md for Gateway-specific bounty scope.

• Node.js 20+
• Express
• MongoDB / Mongoose
• wallet/provider integrations where configured
• JWT authentication
• security headers/CORS/rate limiting
• automated tests

git clone https://github.com/MyZubster-Ecosystem/MyZubsterGateway.git
cd MyZubsterGateway
npm ci

Create .env from the repository template and configure only environment-specific values. Never commit production credentials.

Start using the current package scripts, typically:

npm start

npm test

Payment/settlement work should test negative paths including provider failure, timeout, duplicate/replay, wrong recipient, wrong amount/network and unavailable verification.

Settlement is deliberately separate from normal application flow.

A safe external lifecycle is:

PENDING -> RESERVED/ACCEPTED -> SUBMITTED -> CONFIRMED -> PAID

Additional states may include FAILED, UNSETTLED, DISPUTED and CANCELLED.

Important rules:

• an application/database update is not chain/payment proof;
• a provider/adapter response alone cannot mark PAID;
• transaction id/hash, recipient, asset, network and canonical amount must match expected settlement data;
• unavailable verification must fail closed rather than infer success;
• MYZ in the current core platform is an internal reward/accounting ledger, not automatically an on-chain transaction.

Main areas may include:

Verify the current router/controller source before building an external integration against a historical endpoint list.

Before production deployment verify:

• dependency/security checks;
• secrets from deployment environment, not Git;
• HTTPS/TLS and network restrictions;
• JWT/key rotation;
• authentication/authorization and rate limiting;
• database backup/rollback;
• provider/RPC authentication/network controls;
• idempotency and duplicate prevention;
• observable retry/failure behavior;
• independent settlement verification;
• health checks and monitoring.

Never commit private keys, wallet seeds, passwords or production credentials.

Gateway work can be bountied for API, security, integration, reconciliation, testing and documentation tasks. Issue/PR/merge does not prove external payment. Follow the canonical bounty and settlement contracts linked above.

Create a feature branch, add/update tests, run the relevant checks and open a PR linked to the issue.

MIT License. See LICENSE.