BUILD WITH SHAREAI
Give customers a clear choice about AI usage, your optional fee and each purchase. Build a payment journey they can understand and control.
The experience you’ll design
Pay with ShareAIClear access. Accepted terms. Confirmed purchases.
YOUR IMPLEMENTATION
Keep authorization, accepted terms and confirmed payments explicit in both your product and your implementation.
The customer understands whether they are connecting, using AI or approving a purchase.
The token and operation use the intended account and scope.
Publish understandable offers and track the version each customer has accepted.
New terms do not silently move an existing customer.
Create one intended purchase, verify its paid status and fulfill it once.
Retries, cancellation, declined checkout and limits are handled.
TAKE IT INTO YOUR EDITOR
Copy the complete guide with the implementation goal, required inputs and acceptance checks. Keep code examples, tables and documentation links together.
Ready for your project, in the format you need.
Updated
You’ll distinguish connecting an account, paying for AI usage and confirming a product purchase.
Where you’ll work Your product → Payment experience
Pay with ShareAI lets a customer use their selected ShareAI account in your application. There are two distinct billing flows: customer-funded AI requests under an accepted authorization, and a product purchase that the customer confirms in checkout. Optional Builder markup is an additional agreement on AI usage.
| Customer action | What happens | Required access |
|---|---|---|
| Connect a wallet | Creates an authorization for the selected account and accepted terms. No product is bought by clicking Connect. | openid plus the capabilities your app uses. |
| Send an AI request | Uses the authorized account’s eligible AI credits and accepted usage terms. | Applicable inference access; monetization_gateway for accepted Builder markup terms. |
| Confirm a product purchase | Debits the particular purchase only after authorized confirmation. | payments and a successful payment request. |
JamZY’s appointment sample demonstrates the AI usage route. It has no merchant checkout, requests no payments scope and does not claim that connecting purchases a subscription. Use the remaining chapters when you add that separate experience.
Your button and product copy say whether the customer is connecting, using AI or confirming a purchase.
You’ll obtain permission from the intended paying account before an operation uses it.
Where you’ll work Console → Use Cases → Customer authorization
A client ID identifies the platform. An access token represents the accepted customer authorization. A contract version records billing terms. None of these alone proves that a particular product payment was confirmed.
The token belongs to the intended customer and includes the permissions for the operation you are about to perform.
You’ll publish clear usage terms that the customer can review and accept.
Where you’ll work Application → Subscriptions
In Subscriptions, create clearly named offers and explain the additional AI fee. The subscription ID is generated, read-only and scoped to your application. These offers are shared across the app’s platform clients, so you do not maintain a different commercial offer for Web and Android.
Use Estimate to compare network cost, surcharge and builder earnings for the chosen model. Publish a reviewed draft as the next contract version. Customers accept that version during authorization; a published offer is not the same as an accepted customer agreement.
If you only need product payments, use the available free payment-access contract flow rather than inventing an Builder markup. Fixed subscription prices and intervals are not configured by the current usage-offer editor; do not interpret an AI offer as automatic recurring billing.
Your offer accurately describes what is added to AI cost. The customer-facing consent shows the same published terms.
You’ll introduce a new contract while keeping track of the terms each account has accepted.
Where you’ll work Subscriptions → Contracts
Prepare changes in the next contract draft. Existing authorizations retain their accepted subscription and version until the customer accepts a replacement. Compare account counts and distributions in the subscription overview instead of assuming every account uses the latest version.
Tell customers what changes and send them through the consent flow to accept a new version when required. A refreshed token cannot manufacture acceptance. Keeping accepted contracts is the default transition. Choosing to require renewed consent before further actions deliberately interrupts existing access until the customer approves the new terms; review that impact before publication. Any permitted decrease must follow the accepted contract’s rules; a fee increase requires the customer’s approval.
Keep the application-level view and the identity boundary separate. Platform-specific customer identifiers remain scoped to their client context even when the commercial overview aggregates the whole application.
You can identify which contract each account accepted and explain how it can move to the next one.
You’ll create one intended purchase, obtain confirmation and verify payment before delivery.
Where you’ll work Your backend → ShareAI checkout → Payment verification
This chapter extends the appointment example with a separate product purchase. Run it only after enabling payments and obtaining a customer token with that scope. Keep the order and payment state on your backend.
# Real payment request: use scoped test access and an intentional amount.
curl --fail-with-body 'https://api.shareai.now/api/v1/console/builder/payments' \
-H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
-H 'Content-Type: application/json' \
-H 'Idempotency-Key: YOUR_UNIQUE_ORDER_REFERENCE' \
--data '{"title":"JamZY appointment preparation pack","amount":"1.00"}'curl --fail-with-body --get \
'https://api.shareai.now/api/v1/console/builder/payments' \
-H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
--data-urlencode "id=$SHAREAI_PAYMENT_ID"| Payment status | What your product should do |
|---|---|
| pending | Show that customer confirmation is still required. Do not fulfill yet. |
| paid | Verify against your server’s order, then fulfill once. |
| declined | Respect the decision; let the customer choose whether to try another purchase. |
| expired | Create a fresh request with a new idempotency key when the customer wants to retry. |
Use only a checkout URL returned by the trusted API, and validate it against your integration’s allowed destination policy. A return-to-app success message is not payment evidence. The payer cannot purchase from their own Builder account.
If you support an existing fixed-price subscription contract, the payment API can use its accepted terms for an explicitly confirmed period. Do not send a made-up recurring price or charge a new period silently. JamZY’s downloadable appointment sample does not implement that extension.
No order is delivered until your backend verifies paid, and repeating the confirmation flow cannot deliver or debit the same order twice.
You’ll handle credit limits and disconnection without duplicate charges or unexpected account changes.
Where you’ll work Your application → Billing recovery
AI usage and product purchases have different eligible-credit rules. An account may have AI-eligible credits that cannot pay for a product. Handle insufficient funds and per-application spending limits using the API error and customer billing destination.
Show the customer the chosen paying account, the action that failed and a route to manage credits or limits. The customer controls their own cap; the app owner cannot raise it. Do not silently switch from an organization to a personal account to make a charge succeed.
Disconnecting should revoke the relevant authorization and clear the local session. It stops future authorized requests; it does not undo a purchase already confirmed or automatically cancel a separate paid commitment. Refresh failure, grant revocation and payment expiry require distinct recovery messages.
Insufficient-credit and limit errors leave the customer informed and in control, with no accidental duplicate order or payer change.
You’ll test the successful path and its failure cases before including the platform in publication.
Where you’ll work OAuth settings → Verification
Use the application-wide tester roster and an eligible paying account different from the Builder. There are at most five tester places including pending invitations. Complete real endpoint and scope verification for every platform included in publication.
Your integration distinguishes accepted access, accepted terms, requested payment and confirmed payment, and handles the failure path for each.
Select the personal or organization account that will own the program enrollment before applying. Organizations can submit an application before verification, but staff approval alone does not activate access. Complete organization email and company verification from the onboarding checklist in Console. An approved organization remains Pending verification until both checks are complete. Builder, Provider and Creator programs follow this rule.
View Monetization Gateway pricing · Explore ShareAI for Startups · Scopes and permissions
Your public Terms & Conditions, Privacy Policy and deletion instructions must match the application and remain reachable without sign-in. ShareAI program acceptance, Monetization Gateway approval, the customer’s OAuth permission and the accepted billing contract are separate decisions. Refresh cannot add permissions or accept new commercial terms.
The legacy surcharge scope remains accepted for existing integrations. New examples use monetization_gateway. Keep existing wire fields such as surcharge_bps and surcharge_percentage unchanged.
View Monetization Gateway pricing · Explore ShareAI for Startups · Scopes and permissions
Standard charges 5% of the Builder markup. For €2.00 of AI network cost and a 10% markup, the customer pays €2.20. ShareAI receives €0.01 of the €0.20 markup; the Builder has €0.19 before Event Ingestion.
The first 1,000 settled Production Monetization Gateway requests are free each calendar month (UTC), shared across the Builder account. Additional requests cost €0.04 per 1,000 before eligible discounts. One settled request creates one event.
Pay with ShareAI on its own, inference-only access, ordinary account API keys and Staging or testing traffic do not incur Monetization Gateway Event Ingestion.
ShareAI for Startups offers a shared monthly allowance for actual ShareAI fees on an approved application. The current Launch, Growth and Momentum tiers list €1,000, €5,000 and €10,000 per month. The same budget covers ShareAI’s percentage fee on Builder markup and billable Event Ingestion together. It is not a gross-markup allowance, a separate free-event quota or free AI inference. The account’s first 1,000 free events do not consume it.
Remaining Event Ingestion fees are paid from the request’s new Builder earnings, then available Builder AI earnings and unrestricted AI credits. Customer AI charges and product payments stay separate.
ShareAI can approve application-specific fees or fee support for a fixed period or until changed. Review the application’s current pricing and Special Programs in Console for its approved terms, validity and consumed allowance. A tier change or pricing override does not reset the application’s monthly usage.
Launch keeps Log in with ShareAI optional. Growth and Momentum require it; Momentum also requires the official ShareAI for Startups badge in the application footer. ShareAI checks the badge weekly. Confirmed attempts to bypass requirements can lead to demotion, removal from the Startup Program or withdrawal from the Marketplace under the accepted program terms.
Enterprise rates are configured by the ShareAI team for the Builder account after agreeing a personalized offer. The assigned percentage and event rate apply to future requests.
View Monetization Gateway pricing · Explore ShareAI for Startups · Scopes and permissions