Payment automation covers the machinery that moves value inside XOM without manual intervention: credit balances, subscription plans, promotional codes, and the administrative settings that govern them. Real-money settlement sits outside this system by design.
01Credits
Credits are XOM's metered spend unit. Each user record carries a balance, and every movement is written as a typed transaction with a user ID, amount, type, description, timestamp, and an optional reference linking it to the entity that caused it — a post, a promotion code, or a plan.
Five transaction types are defined: purchase, subscription, promotion, usage, and refund. That taxonomy is what makes the balance auditable rather than merely current — a balance can be explained by replaying the transactions that produced it.
Operations that consume credits declare their cost centrally rather than inline, with separate rates for image upload, video upload, audio upload, and premium containers. A companion package store handles credit bundles available for purchase.
02Subscriptions
Subscription plans are stored as records rather than hardcoded tiers. The plan service supports listing all plans with an option to include inactive ones, retrieving a plan by ID, creating a plan, and updating an existing plan. Because plans are data, adding or repricing a tier is a record change, not a deployment.
A subscription service handles the user-to-plan relationship and a separate analytics module reports on it.
03Promotions
The promotion layer has three parts: a code manager for creating and validating individual codes, a bulk generator for producing codes in batches for campaigns, and an analytics module for tracking redemption and performance. Promotional credit grants flow into the same transaction log as any other credit movement.
04Administrative controls
The monetization panel in the admin console exposes the platform-level levers: the XP-to-currency conversion rate, a payouts enable toggle, a tipping enable toggle, and a revenue-sharing percentage. These persist to a monetization configuration document, and every change is written to the administrative audit log with the acting admin and the before and after values.
05The settlement boundary
This is the part to be precise about. XOM owns its in-app economy — credit and currency balances, plan state, promotion redemption — and those are real and stored. Real-money settlement, meaning card capture and creator cash-out, is treated as a separate financial boundary handled by the platform group's dedicated settlement path together with a payment processor, not by XOM directly.
An administrative transaction client exists that describes the intended operations — list transactions, convert XP to currency, adjust a balance, process a payout, manage a subscription, issue a refund, and pull revenue summaries and trends. It targets server endpoints that XOM's static deployment does not serve, so treat it as the shape of the future interface rather than a live integration. Confirm the current state of payouts before describing creator cash-out as available.