# Pay with ShareAI, from consent to checkout

Give customers a clear choice about AI usage, your optional fee and each purchase. Build a payment journey they can understand and control.

25–35 minutes · 10 practical steps · Application builders · product & engineering

YOUR IMPLEMENTATION

## A payment flow you can explain and verify.

Keep authorization, accepted terms and confirmed payments explicit in both your product and your implementation.

### Access with a clear purpose

The customer understands whether they are connecting, using AI or approving a purchase.

**You can verify it when**

The token and operation use the intended account and scope.

### Contracts you can follow

Publish understandable offers and track the version each customer has accepted.

**You can verify it when**

New terms do not silently move an existing customer.

### Confirmation before delivery

Create one intended purchase, verify its paid status and fulfill it once.

**You can verify it when**

Retries, cancellation, declined checkout and limits are handled.

## Choose what your customer pays for

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 · appointment reference application [Enlarge screenshot ↗](https://shareai.now/shareai-assets/L3dwLWNvbnRlbnQvdGhlbWVzL3NoYXJlYWktZnJvbnRlbmQtdGhlbWUvYXBwL21vZHVsZXMvZ3VpZGFuY2UvYXNzZXRzL2phbXp5LnBuZw.DZt_5dnvNF40T34-7MJsXw?v=219eca92cbe5)

Local appointment scheduling and customer-funded AI preparation are separate actions. No calendar invitation is sent by this demo.

1. Choose the appointment type and duration.
2. Pick an available demo slot.
3. Connect ShareAI to use the optional AI assistant.
4. AI runs only after this explicit action; booking alone does not call ShareAI.

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.

**You’re ready to continue when**

Your button and product copy say whether the customer is connecting, using AI or confirming a purchase.

Need the details?[Full JamZY setup ↗](https://shareai.now/blogs/product/builder-program/guides-how-to/how-to-connect-an-application-to-shareai-builder-step-by-step/)[Scopes ↗](https://shareai.now/docs/api/builders/auth/scopes/)

## Get the customer’s authorization

You’ll obtain permission from the intended paying account before an operation uses it.

Where you’ll work Console → Use Cases → Customer authorization

1. Create the application and complete onboarding, public information and platform callbacks. Enable the relevant use cases in Console.
2. For Builder markup, complete its access request and wait for approval where required. For purchases, enable Pay with ShareAI and configure the required payment-access contract in Subscriptions.
3. Request enabled scopes through Authorization Code + S256 PKCE. Use payments for product checkout, inference for AI at network cost, and monetization\_gateway for an approved AI markup. Ask only for the capabilities the application actually uses.
4. Have the customer select the correct personal or organization account and accept the displayed terms. Additional scopes or changed terms need authorization again; refresh does not grant them.

Use Cases [Enlarge screenshot ↗](https://shareai.now/shareai-assets/L3dwLWNvbnRlbnQvdGhlbWVzL3NoYXJlYWktZnJvbnRlbmQtdGhlbWUvYXBwL21vZHVsZXMvZ3VpZGFuY2UvYXNzZXRzL3VzZS1jYXNlcy5wbmc.zRU3Lp1TsQuYD7ClWUWS-X?v=090d8c81e6da)

Log-in with ShareAI, Pay with ShareAI and Monetization Gateway have separate configuration and approval states.

1. Configure Login with ShareAI.
2. Enable customer-funded usage.

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.

**You’re ready to continue when**

The token belongs to the intended customer and includes the permissions for the operation you are about to perform.

Need the details?[Customer authorization ↗](https://shareai.now/docs/api/builders/auth/authorization-code-pkce/)[Accepted terms ↗](https://shareai.now/docs/api/builders/auth/billing-agreements/)

## Explain your AI fee in an offer

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.

Subscriptions · Overview [Enlarge screenshot ↗](https://shareai.now/shareai-assets/L3dwLWNvbnRlbnQvdGhlbWVzL3NoYXJlYWktZnJvbnRlbmQtdGhlbWUvYXBwL21vZHVsZXMvZ3VpZGFuY2UvYXNzZXRzL3N1YnNjcmlwdGlvbnMucG5n.1fAD7CKPa38_SZFh5zuI9P?v=f1ef4ee6680b)

New applications start without a published contract. Add an offer before publishing its terms.

1. Create an offer in its own editor.

Subscriptions · offer editor [Enlarge screenshot ↗](https://shareai.now/shareai-assets/L3dwLWNvbnRlbnQvdGhlbWVzL3NoYXJlYWktZnJvbnRlbmQtdGhlbWUvYXBwL21vZHVsZXMvZ3VpZGFuY2UvYXNzZXRzL3N1YnNjcmlwdGlvbi1lZGl0b3IucG5n.ajS-FCMdefa7Br_i-9U6yV?v=028a19d93ad7)

An illustrative draft offer. Its generated subscription ID is read-only and scoped to this application.

1. Use a customer-facing offer name.
2. Set the AI surcharge for this offer.

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.

**You’re ready to continue when**

Your offer accurately describes what is added to AI cost. The customer-facing consent shows the same published terms.

Need the details?[Immutable billing agreements ↗](https://shareai.now/docs/api/builders/auth/billing-agreements/)

## Let customers choose new 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.

Subscriptions · Contracts [Enlarge screenshot ↗](https://shareai.now/shareai-assets/L3dwLWNvbnRlbnQvdGhlbWVzL3NoYXJlYWktZnJvbnRlbmQtdGhlbWUvYXBwL21vZHVsZXMvZ3VpZGFuY2UvYXNzZXRzL2NvbnRyYWN0cy5wbmc.XbUHyTwHQDJk3rDHQe4-gs?v=a43ae1273eb9)

Contract history and accepted-account distributions appear after publication and customer consent.

1. Review published contract versions.

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’re ready to continue when**

You can identify which contract each account accepted and explain how it can move to the next one.

Need the details?[Contract transition rules ↗](https://shareai.now/docs/api/builders/auth/billing-agreements/)[Customer identity boundaries ↗](https://shareai.now/docs/api/builders/auth/pairwise-identities/)

## Confirm a purchase before fulfilling it

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.

```bash
# 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"}'
```

1. Save the returned payment ID and checkout URL with the order. Use an exact decimal amount string; avoid floating-point money calculations.
2. Open the returned checkout URL. ShareAI presents the purchase and the payer. The customer must confirm using the account that authorized your app. Opening checkout does not debit it.
3. Read the payment from the API with the same customer authorization. Fulfill the order only after the verified status is paid.
4. Retry the same intended purchase with the same idempotency key. A different purchase needs a new key. Never reuse a key for changed terms.

```bash
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.

**You’re ready to continue when**

No order is delivered until your backend verifies paid, and repeating the confirmation flow cannot deliver or debit the same order twice.

Need the details?[Payment endpoint & response reference ↗](https://shareai.now/docs/api/builders/payments/)

## Help customers recover from a billing issue

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.

Customers [Enlarge screenshot ↗](https://shareai.now/shareai-assets/L3dwLWNvbnRlbnQvdGhlbWVzL3NoYXJlYWktZnJvbnRlbmQtdGhlbWUvYXBwL21vZHVsZXMvZ3VpZGFuY2UvYXNzZXRzL2N1c3RvbWVycy5wbmc.qbIDq-R5JMA6K48ws4kWaB?v=cc0470083fec)

The application view brings connected accounts together without displaying internal organization database IDs.

1. Customer management is aggregated for the application.

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.

**You’re ready to continue when**

Insufficient-credit and limit errors leave the customer informed and in control, with no accidental duplicate order or payer change.

Need the details?[Billing errors & limits ↗](https://shareai.now/docs/api/builders/billing-errors-and-spending-limits/)[Revoking access ↗](https://shareai.now/docs/api/builders/auth/revoke-introspect/)

## Verify the complete payment journey

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.

Web · Verification [Enlarge screenshot ↗](https://shareai.now/shareai-assets/L3dwLWNvbnRlbnQvdGhlbWVzL3NoYXJlYWktZnJvbnRlbmQtdGhlbWUvYXBwL21vZHVsZXMvZ3VpZGFuY2UvYXNzZXRzL3ZlcmlmaWNhdGlvbi5wbmc.xLD6z4RV0ddX6p0qkaLhqc?v=d758a8f881d9)

A new integration shows pending checks until real successful calls are recorded. This reference draft has not passed review.

1. Console records actual endpoint success.
2. Every requested scope must also be exercised.

1. Test authorization accepted and canceled; confirm the selected customer/account boundary.
2. Test a successful scoped AI request for inference or monetization\_gateway and the required successful payment API call for payments. A payment request may be pending without a debit; a full checkout test additionally verifies explicit confirmation and paid.
3. Test duplicate requests, declined and expired checkout, insufficient eligible credits, account spending limits, expired tokens, refresh rotation and revoked authorization.
4. Check Customers, Subscriptions and Analytics for the resulting customer, accepted terms and attributed activity. Confirm that sensitive credentials and internal organization IDs do not appear in customer-facing UI.
5. Only include platforms whose configuration and recorded checks pass. Exclude unfinished platforms or remove them; then submit the app from Dashboard.

**You’re ready to continue when**

Your integration distinguishes accepted access, accepted terms, requested payment and confirmed payment, and handles the failure path for each.

Need the details?[Application launch checklist ↗](https://shareai.now/blogs/product/builder-program/guides-how-to/how-to-connect-an-application-to-shareai-builder-step-by-step/#verify)[Builder API reference ↗](https://shareai.now/docs/api/builders/)

## Organization verification and program access

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](https://shareai.now/builders/monetization-gateway/#mg-pricing) · [Explore ShareAI for Startups](https://shareai.now/startup-program/) · [Scopes and permissions](https://shareai.now/docs/api/builders/auth/scopes/)

## Permissions and accepted terms

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](https://shareai.now/builders/monetization-gateway/#mg-pricing) · [Explore ShareAI for Startups](https://shareai.now/startup-program/) · [Scopes and permissions](https://shareai.now/docs/api/builders/auth/scopes/)

## Gateway fees and Startup support

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](https://shareai.now/builders/monetization-gateway/#mg-pricing) · [Explore ShareAI for Startups](https://shareai.now/startup-program/) · [Scopes and permissions](https://shareai.now/docs/api/builders/auth/scopes/)

Source: https://shareai.now/blogs/product/builder-program/guides-how-to/pay-with-shareai/