SafeGate v5.4 / Merchant API Key Lifecycle / Public Mock

Merchant API Key Lifecycle Mock

This page shows how a future merchant API key lifecycle can be designed without exposing real keys, backend secrets, service role credentials, wallet passphrases, or production API claims.

Public boundary: This is a lifecycle mock. It is not a production API key system, not a production merchant console, not a production public API, does not expose real API keys, does not expose backend secrets, and does not claim Pi Mainnet settlement proof.

1. Mock Lifecycle Console

Merchant ID Environment

Lifecycle Result

Click “Create Mock API Key” to run the lifecycle mock.

2. Lifecycle States

CREATED

A mock API key record is created for a merchant, but the raw key is not exposed as a real credential.

ACTIVE

A future production key would be allowed to access bounded merchant-scoped verification endpoints.

ROTATED

A future merchant can rotate credentials. Old keys should be retired and invalidated safely.

REVOKED

Revoked keys must fail closed and should not be allowed to verify receipts.

3. Mock Create Response

{
  "ok": true,
  "mode": "public_mock",
  "statusCode": 201,
  "code": "MERCHANT_API_KEY_CREATED",
  "merchantId": "merchant_demo_001",
  "environment": "testnet_sandbox",
  "keyId": "sg_key_mock_001",
  "keyPreview": "sg_mock_****_demo",
  "rawKeyReturned": false,
  "productionApi": false,
  "backendSecretExposed": false,
  "safeStorageRule": "Only hashed/derived key material should be stored server-side in future production."
}

4. Future Verification Header Boundary

In a future production boundary, merchants should not send backend secrets. They would send merchant-scoped credentials through bounded headers. This page does not create or expose real credentials.

{
  "X-SafeGate-Merchant-Id": "merchant_demo_001",
  "X-SafeGate-Key-Id": "sg_key_mock_001",
  "X-SafeGate-API-Key": "masked_future_credential_not_exposed_here",
  "X-Idempotency-Key": "future_replay_control_token"
}

5. Security Rules

Never expose backend secrets, service role keys, wallet passphrases, access tokens, or raw API credentials.
Store only hashed or derived API key material in future production systems.
Scope keys to merchant, environment, permission, rate limit, and lifecycle state.
Revoked or rotated keys must fail closed.
Rate limits should be merchant/API-key scoped, not only IP-based.
Unauthorized keys should not disclose whether a receipt exists.
All lifecycle changes should produce durable audit events.

6. Future Lifecycle Audit Events

[
  "MERCHANT_API_KEY_CREATED",
  "MERCHANT_API_KEY_ACTIVATED",
  "MERCHANT_API_KEY_ROTATED",
  "MERCHANT_API_KEY_REVOKED",
  "MERCHANT_API_KEY_RATE_LIMITED",
  "UNAUTHORIZED_MERCHANT_KEY_ATTEMPT"
]

7. Why This Matters

v5.3 showed how a merchant can verify receipts through a mock console. v5.4 shows how the merchant should be connected safely in the future: scoped API keys, lifecycle controls, rate limits, revocation, rotation, and audit events.

Reviewer takeaway: SafeGate now shows a path from payment evidence to receipt verification, API contract, merchant console, and merchant authentication lifecycle design.