Digital Service Monetization and Democratization
Important note for SCF reviewers: Code is private and proprietary. During phase 3 (see issue labels) the Soroban smart contract will be finalized and made public. The ApiCharge server platform binaries will be kept private permanently. Docker Images for the ApiCharge templates will not have their Dockerfiles made public. The Mac, Windows and Linux native wallet desktop manager apps will be closed source, and the future iOS, Android and Smart TV consumer apps will be closed source BUT with the support of the community, whitelabel/skeleton apps can be derived from these with ApiCharge and StreamCharge proprietary features removed, so that anyone may build native Stellar-integrated apps from a stable starting point, with secure key management, account management, and on/off ramping integrated.
Please use this repo to log issues and request features.
Information, guidance, documentation, and SDK usage code will be transferred to this site for the ApiCharge desktop B2B apps, mobile consumer apps, and server stablecoin/digital currency pricing and payment gateway.
Public beta progress planned for the week of 27/Oct/2025
More to come...
Your input, feedback and help is warmly appreciated.
Welcome to ApiCharge!
For the full architecture and detailed technical documents of the project, please refer to the submission video and the official documentation
This section is for the benefit of SCF reviewers who need a distilled version of the platform, its changes, and direction for ML and AI use cases.
The ApiCharge project is a platform for monetization of digital services. It provides tools and technologies for providers to productionize and charge for digital services both new and existing, removing friction wherever possible, taking advantage of stablecoin and new stablecoin supportive legislation, such as MiCA and GENIUS, to allow creators and developers to own their services, without payment gateways, bureaucracy, or middlemen. This submission is about bringing the platform to market through a narrow focus on ML/AI developers. Right now the ML/AI creator or developer has only 2 options: do-it-yourself and learn IT infrastructure, scaling, pricing, payments and more, or use a middleman like Replicate.com or HuggingFace, or even RapidAPI, who take their cut. Consumers of those hosted services then have to consider platform lockin. ApiCharge will bring a third option to ML/AI developers: use ApiCharge to deploy models and workflows, manage infrastructure, collect revenue and modify pricing.
The ApiCharge Desktop Apps are installed by users (in this submission, ML / AI devs ). They add their ML models to the local library or later configure access to other libraries, such as HuggingFace. Their aim is to productionize and monetize. They click their model, hit deploy, choose a compatible template from the ApiCharge.com template library (the apps recognise what models are compatible with which server templates) and request a machine. The app takes the template requirements, and through the existing Vast.ai integration (later other marketplaces), the machine is deployed, the server installed, and the app given a direct, secret connection to the server. From there the ApiCharge Desktop app allows pricing management, publication of the service on the Apicharge.com catalogue/marketplace (when implementation is completed for that feature) Furthermore, each ApiCharge server already offers its own automatically generated HTML page and OpenAPI technical pages.
The same app is used to discover and consume services, or when the service is browsed to on the web, users can be deeplinked into the native app to install it or to the payment page. The app also allows the user to import services they know of privately. Once the services are in the local service catalogue, their offerings can be asked for an actual quote, and the service access purchased in-app, as the app is a native wallet with fiat->stable on ramps.
It is important to note that the Wrapped Infrastructure ApiCharge Templates, Docker images that wrap popular servers by embedding ApiCharge into the image and gating traffic through it, always include some form of Stellar RPC server, with ports disabled by default. For this reason, the "base" image with no server wrapped is the same as the Wrapped Infrastructure Stellar RPC server (an example here: https://mainnet.stellar.apicharge.com ) , except with configuration set to expose Stellar. Consequently, any ApiCharge server, with the switch flipped, can become a Stellar RPC server in future. If Stablecoin-native UX is desired and enabled in that image, then all ApiCharge Stellar servers can allow the user to also generate passive USDc income as a Stellar Circle provider (or potentially any other stablecoin).
There are various other architectures supported too - as the existing ApiCharge server binaries allow for clustered configuration behind load balancers, and other HA support.
The core of ApiCharge is the ApiCharge Subscription Protocol, a unique approach to API monetization that combines the flexibility of micropayments with the predictability of subscriptions, offering unprecedented pricing control over network guaranteed qualities of service. Unlike other HTTP micropayment protocols, ApiCharge also offers safe flexibility in pricing/service-level strategy control: Existing GrantedAccessTokens, mutually signed by client and server, and witnessed by the Soroban contract, specify the quality of service in the token data. This means that the Quote system can be modified without affecting existing on-going subscriptions. This avoids situations like the recent debacle with Cursor, where multi-thousand dollar access purchases were capped post-hoc, causing uproar and customer exodus.
An ApiCharge Subscription is a time-bound, quality-of-service guaranteed access grant to a specific API route. Unlike traditional micropayments that charge per API call, ApiCharge Subscriptions provide access for a specific duration (minutes to months) with defined usage parameters.
The protocol flow usually consists of the following steps:
- Client requests a signed Quote containing available services and their pricing (Quotes have an expiration and may be saved so this step may not be always necessary.)
- Client selects a Route Quote and requests a Purchase Instruction
- Client authorizes payment via Stellar Soroban blockchain, simply by signing the Purchase Instruction's "AuthorizationToSign" message.
- Server issues a GrantedAccessToken representing the purchased ApiCharge Subscription
- Client creates AccessTokens from the GrantedAccessToken to access services, by signing them or signing them with a custom expiration.
- ApiCharge validates tokens and enforces purchased quality-of-service parameters, maintaining persistent quality of service data for the duration of the GrantedAccessToken
This approach solves the fundamental problems of API monetization by batching multiple service invocations into a single payment while maintaining the flexibility of pay-as-you-use models.
After the changes in the submission roadmap, protocol variants will be on offer:
- Client hits server service route without paid access
- Client receives 402 HTTP message (as currently implemented) but with payment guidance in multiple forms, AI guidance, x402 options, and even a directly signable payment auth message
- Client signs and posts to the ApiCharge endpoint of that server
- Client receives and generates client-signed access tokens with duration of their choice
Example:
- Request Signed Quote: Client requests a signed Quote containing price, duration, and quality-of-service parameters for various service routes (RouteQuotes). ApiCharge returns a cryptographically signed Quote with a time-limited validity window.
- Purchase Instruction Request: Client requests a purchase instruction for a selected RouteQuote, usually a minutes or hours of a certain quality of service for a single route. ApiCharge prepares and returns a transaction for the payment 3platform's smart contract.
- Client Authorise Payment: Client signs the transaction (which contains the RouteQuote) and returns it to ApiCharge. ApiCharge submits the signed transaction to the payment platform. 4.** Payment Execution**: The payment platform's smart contract verifies the quote authenticity, validates expiration, and transfers funds.
- ApiCharge Subscription Issuance: ApiCharge issues a signed ApiCharge Subscription containing the original service parameters (the RouteQuote).
- Service Use: Client creates AccessTokens from the ApiCharge Subscription (with client-controlled lifetimes) and requests service access by adding it to either a header or cookie. ApiCharge validates the AccessToken, enforces purchased quality-of-service parameters, and proxies the request to the service.