Security and certification

Signing, verification, test scenarios, and production approval
View as Markdown

Security and certification

Signature contract

  • Algorithm: RSA with SHA-256.
  • Padding: PKCS#1 v1.5.
  • Input: exact UTF-8 JSON bytes sent on the wire.
  • Header: Base64 signature in Signature.
  • Key direction: the operator private key signs operator-to-Wuzzlo calls, which Wuzzlo verifies with the operator public key. The Wuzzlo private key signs wallet callbacks, which the operator verifies with the Wuzzlo public key.

Do not parse and reserialize the JSON before verification. Even equivalent JSON can have different bytes because of whitespace, escaping, number formatting, or property ordering.

Verification pseudocode

rawBody = readRequestBodyBytes()
signature = base64Decode(headers["Signature"])
if !rsaSha256Pkcs1Verify(wuzzloPublicKey, rawBody, signature):
return HTTP 200 { "balance": 0, "status": "OP_INVALID_SIGNATURE" }
request = parseJson(rawBody)
process(request)

Apply a reasonable request-size limit, HTTPS, modern TLS, secret rotation, least-privilege database access, and network allowlisting where agreed. Signature verification remains mandatory even when the source IP is allowlisted.

Certification test user

Provide a staging user that:

  • is active and resolvable through /auth/login;
  • uses the configured currency;
  • has enough balance for repeated debit, rollback, and settlement cycles;
  • is isolated from real customers;
  • can be inspected by the operator team during troubleshooting.

Scenarios Wuzzlo validates

AreaRepresentative checks
AuthenticationValid token resolves the expected user; invalid token is rejected.
BalanceFunded balance is returned without mutation.
DebitSuccess, insufficient funds, duplicate reqId, and reused transactionId.
SettlementSuccessful credit, duplicate delivery, unknown debit, rolled-back debit, and already-settled debit.
RollbackSuccess, duplicate delivery, unknown transaction, amount mismatch, and rollback after settlement.
ValidationInvalid operator, missing fields, invalid amounts, and unsupported precision.
SecurityMissing or corrupted signature returns exactly OP_INVALID_SIGNATURE and leaves balance unchanged.
DurabilityResults remain idempotent across retries and service restarts.

The certification runner checks both the business status and the balance. Returning the correct balance with the wrong status is a failure.

Before requesting certification

  • Deploy the staging wallet API on its final HTTPS hostname.
  • Install the correct Wuzzlo staging public key.
  • Disable every signature-verification bypass.
  • Confirm the configured operatorId, currency, base URL, and callback paths.
  • Seed and verify the funded test user.
  • Test concurrent duplicate requests and application restarts.
  • Confirm database backups, monitoring, and an incident contact.
  • Call Wuzzlo game listing and login APIs with the operator staging private key.

Production approval

After certification, repeat the key exchange and configuration review for production. Wuzzlo activates only the approved public key, wallet URL, currency, callback paths, and games. Use a controlled first launch, verify the resulting debit and settlement in both systems, and keep engineering contacts available during the launch window.

A SkipSignatureVerification, debug bypass, placeholder key, or permissive demo authentication must never be enabled in certification or production.