MobiMatter eSIM Provider Operations

Skyte integrates MobiMatter through the global eSIM store provider manager under the slug mobimatter. It is not a local telecom activation operator. Catalog browsing stays database-only; the provider API is used by scheduled sync, a single pre-payment validation, wallet health, post-payment fulfillment, and reconciliation.

Deployment setup

1. Apply the forward Drizzle migration and custom RLS migration. Do not deploy API code that selects the new encrypted credential columns before the migration is applied.

2. Configure the API deployment:

   ESIM_STORE_PROVIDERS=mobimatter
   MOBIMATTER_CALLBACK_URL=https://<api-origin>/webhooks/mobimatter
   MOBIMATTER_MAX_CONCURRENCY=2

   The callback must be HTTPS. MobiMatter Merchant ID and API key do not belong in environment files.

3. In Admin → Plugins → MobiMatter, save both credentials. They are encrypted with Skyte's ENCRYPTION_KEY, are write-only, and can be rotated independently after first setup.

4. Run Test connection. This makes only GET /api/v2/merchant/balance; it never creates or completes an order.

5. Queue Sync catalog, then inspect imported products and pricing before enabling a live test.

6. Run a low-value purchase only with explicit operational approval and real credentials.

MobiMatter has no sandbox. POST /api/v2/order authorizes wallet funds and PUT /api/v2/order/complete captures them. Skyte never retries either write. The fulfillment worker persists the provider order ID before completion and recovers uncertain calls only through GET /api/v2/order/{orderId}.

Traffic and rate behavior

MobiMatter publishes no numeric request quota. Skyte bounds traffic through:

• scheduled full catalog reads (ESIM_SYNC_INTERVAL_MS, default five minutes);
• database-only customer browse and product detail pages;
• one live product read before each fresh payment intent (idempotent retries skip it);
• 60-second wallet-health caching;
• MOBIMATTER_MAX_CONCURRENCY across provider requests;
• no automatic retry wrapper for provider writes.

MobiMatter HTTP 429 means product out of stock, not rate limiting. Skyte marks the local product inactive for manual review and does not retry the provider write. HTTP 402 (wallet balance) and 455 (upstream provider unavailable) are also terminal for that write.

Webhooks and delayed KYC

esim_delayed completion callbacks are verified with MobiMatter's documented RSA-SHA256 public key over orderId.merchantId.providerName. Skyte also compares the callback merchant ID with the encrypted configured account. The webhook table stores only provider slug, external order ID, event type/state, provider update time, receipt time, and queue time. Callback QR/LPA/ICCID data is discarded; the worker fetches the authoritative order through the provider client.

Duplicate callbacks are idempotent on provider plus external order ID. A queue failure returns a non-2xx response so MobiMatter retries delivery. Sparse GET reconciliation is scheduled after the approximately two-hour webhook retry window and shortly after the 24-hour KYC expiry boundary. Both fallbacks are one-shot: the two-hour check leaves the expiry check in place, and a still-pending order at the expiry check is parked for operational review instead of scheduling an unbounded poll loop.

If KYC expires, MobiMatter refunds the merchant wallet, not the Skyte customer. The order is marked for operational attention; customer refunds remain a manual process in this scope.

Deferred scope

Top-ups, replacements, usage APIs, provider email notifications, and automated provider/customer refunds are intentionally not implemented. Do not infer support for these flows from the lower-level client types.

Rollback notes

Disable new traffic by removing mobimatter from ESIM_STORE_PROVIDERS and redeploying. This makes the registry omit the adapter and the existing orphan-provider safety pass disables its local catalog. Preserve encrypted settings, store orders, webhook receipts, and audit rows for recovery and financial traceability. Do not drop the new columns/table as an operational rollback.