Acces cu un scop clar
Clientul înțelege dacă se conectează, folosește AI sau aprobă o achiziție.
Tokenul și operațiunea utilizează contul și domeniul intenționat.
CONSTRUIEȘTE CU SHAREAI
Oferă clienților o alegere clară despre utilizarea AI, taxa ta opțională și fiecare achiziție. Construiește o experiență de plată pe care să o înțeleagă și să o controleze.
Experiența pe care o vei proiecta
Plătește cu ShareAIAcces clar. Termeni acceptați. Achiziții confirmate.
IMPLEMENTAREA TA
Păstrează autorizarea, termenii acceptați și plățile confirmate explicite atât în produsul tău, cât și în implementare.
Clientul înțelege dacă se conectează, folosește AI sau aprobă o achiziție.
Tokenul și operațiunea utilizează contul și domeniul intenționat.
Publică oferte ușor de înțeles și urmărește versiunea pe care fiecare client a acceptat-o.
Noii termeni nu modifică în tăcere un client existent.
Creează o achiziție intenționată, verifică starea plătită și îndeplinește-o odată ce este confirmată.
Retrageri, anulări, finalizări refuzate și limite sunt gestionate.
DU-O ÎN EDITORUL TĂU
Copiază ghidul complet cu obiectivul implementării, intrările necesare și verificările de acceptare. Păstrează exemplele de cod, tabelele și linkurile de documentație împreună.
Gata pentru proiectul tău, în formatul de care ai nevoie.
Actualizat
Vei distinge conectarea unui cont, plata pentru utilizarea AI și confirmarea unei achiziții de produs.
Unde veți lucra Produsul dvs. → Experiența de plată
Pay with ShareAI permite unui client să utilizeze contul selectat ShareAI în aplicația dvs. Există două fluxuri de facturare distincte: cereri AI finanțate de client sub o autorizare acceptată și o achiziție de produs pe care clientul o confirmă la checkout. Marcajul opțional Builder este un acord suplimentar privind utilizarea AI.
| Acțiunea clientului | Ce se întâmplă | Acces necesar |
|---|---|---|
| Conectați un portofel | Creează o autorizare pentru contul selectat și termenii acceptați. Niciun produs nu este cumpărat prin clic pe Conectare. | openid plus capabilitățile pe care aplicația ta le utilizează. |
| Trimite o cerere AI | Utilizează creditele AI eligibile ale contului autorizat și termenii de utilizare acceptați. | Acces de inferență aplicabil; monetization_gateway pentru termenii de marcaj acceptați Builder. |
| Confirmă achiziția unui produs | Debitează achiziția respectivă doar după confirmarea autorizată. | payments și o cerere de plată reușită. |
JamZY’s exemplul de programare demonstrează ruta de utilizare AI. Nu are checkout de comerciant, nu solicită domeniul de plăți și nu pretinde că conectarea achiziționează un abonament. Utilizează capitolele rămase când adaugi acea experiență separată.
Butonul și textul produsului tău indică dacă clientul se conectează, utilizează AI sau confirmă o achiziție.
Vei obține permisiunea de la contul plătitor vizat înainte ca o operațiune să îl utilizeze.
Unde veți lucra Consolă → Cazuri de utilizare → Autorizarea clientului
payments pentru checkout de produs, inference pentru AI la costul rețelei și monetization_gateway pentru un marcaj AI aprobat. Solicitați doar capabilitățile pe care aplicația le utilizează efectiv.Un client ID identifică platforma. Un token de acces reprezintă autorizarea clientului acceptată. O versiune de contract înregistrează termenii de facturare. Niciunul dintre acestea singur nu dovedește că o plată specifică pentru produs a fost confirmată.
Tokenul aparține clientului vizat și include permisiunile pentru operațiunea pe care urmează să o efectuezi.
Vei publica termeni de utilizare clari pe care clientul îi poate revizui și accepta.
Unde veți lucra Aplicație → Abonamente
În Abonamente, creează oferte denumite clar și explică taxa suplimentară AI. ID-ul abonamentului este generat, doar în citire și limitat la aplicația ta. Aceste oferte sunt partajate între clienții platformei aplicației, astfel încât să nu menții o ofertă comercială diferită pentru Web și Android.
surcharge pentru această ofertă.Utilizează Estimare pentru a compara costul rețelei, suprataxa și câștigurile builder-ului pentru modelul ales. Publică un proiect revizuit ca următoarea versiune de contract. Clienții acceptă acea versiune în timpul autorizării; o ofertă publicată nu este aceeași cu un acord acceptat de client.
Dacă aveți nevoie doar de payments de produs, utilizați fluxul disponibil de contract de acces la plată gratuit, mai degrabă decât să inventați un marcaj Builder. Prețurile și intervalele fixe ale abonamentului nu sunt configurate de editorul actual de oferte de utilizare; nu interpretați o ofertă AI ca facturare automată recurentă.
Oferta dvs. descrie cu exactitate ceea ce este adăugat la costul AI. Consimțământul orientat către client afișează aceleași termeni publicați.
Veți introduce un nou contract, păstrând evidența termenilor acceptați de fiecare cont.
Unde veți lucra Abonamente → Contracte
Pregătiți modificările în următorul proiect de contract. Autorizările existente își păstrează abonamentul și versiunea acceptată până când clientul acceptă un înlocuitor. Comparați numărul de conturi și distribuțiile în prezentarea generală a abonamentului, în loc să presupuneți că fiecare cont utilizează cea mai recentă versiune.
Spuneți clienților ce modificări au fost făcute și trimiteți-i prin fluxul de consimțământ pentru a accepta o nouă versiune atunci când este necesar. Un token reîmprospătat nu poate fabrica acceptarea. Păstrarea contractelor acceptate este tranziția implicită. Alegerea de a solicita consimțământ reînnoit înainte de alte acțiuni întrerupe deliberat accesul existent până când clientul aprobă noii termeni; revizuiți impactul înainte de publicare. Orice reducere permisă trebuie să urmeze regulile contractului acceptat; o creștere a taxei necesită aprobarea clientului.
Păstrați vizualizarea la nivel de aplicație și limita identității separate. Identificatorii specifici platformei pentru clienți rămân limitați la contextul lor de client, chiar și atunci când prezentarea generală comercială agregă întreaga aplicație.
Puteți identifica ce contract a acceptat fiecare cont și explica cum poate trece la următorul.
Veți crea o achiziție intenționată, obține confirmarea și verifica plata înainte de livrare.
Unde veți lucra Backend-ul dvs. → ShareAI checkout → Verificarea plății
Acest capitol extinde exemplul de programare cu o achiziție separată de produs. Rulați-l doar după activarea plăților și obținerea unui token de client cu acel scop. Păstrați starea comenzii și plății pe backend-ul dvs.
# 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"| Starea plății | Ce ar trebui să facă produsul dvs. |
|---|---|
| în așteptare | Arătați că este necesară confirmarea clientului. Nu finalizați încă. |
| plătit | Verificați în raport cu comanda serverului dvs., apoi finalizați o singură dată. |
| refuzat | Respectați decizia; lăsați clientul să aleagă dacă dorește să încerce o altă achiziție. |
| expirat | Creați o cerere nouă cu o nouă cheie de idempotentă atunci când clientul dorește să încerce din nou. |
Utilizați doar un URL de checkout returnat de API-ul de încredere și validați-l conform politicii de destinație permisă a integrării dvs. Un mesaj de succes de revenire la aplicație nu reprezintă o dovadă de plată. Plătitorul nu poate achiziționa din propriul cont de Builder.
Dacă susțineți un contract de abonament existent cu preț fix, API-ul de plată poate utiliza termenii săi acceptați pentru o perioadă confirmată explicit. Nu trimiteți un preț recurent inventat sau nu taxați o nouă perioadă în mod silențios. JamZY’s mostra descărcabilă de programare nu implementează acea extensie.
Nicio comandă nu este livrată până când backend-ul dvs. verifică plata, iar repetarea fluxului de confirmare nu poate livra sau debita aceeași comandă de două ori.
Veți gestiona limitele de credit și deconectarea fără taxe duplicate sau modificări neașteptate ale contului.
Unde veți lucra Aplicația dvs. → Recuperare facturare
Utilizarea AI și achizițiile de produse au reguli diferite pentru credite eligibile. Un cont poate avea credite eligibile pentru AI care nu pot fi utilizate pentru a plăti un produs. Gestionați fondurile insuficiente și limitele de cheltuieli per aplicație utilizând eroarea API și destinația de facturare a clientului.
Arătați clientului contul de plată ales, acțiunea care a eșuat și o cale pentru a gestiona creditele sau limitele. Clientul controlează propriul plafon; proprietarul aplicației nu îl poate ridica. Nu treceți în mod silențios de la un cont organizațional la unul personal pentru a face o taxă să reușească.
Deconectarea ar trebui să revoce autorizația relevantă și să șteargă sesiunea locală. Oprește cererile autorizate viitoare; nu anulează o achiziție deja confirmată sau nu anulează automat un angajament plătit separat. Eșecul de reîmprospătare, revocarea grantului și expirarea plății necesită mesaje distincte de recuperare.
Erorile de credit insuficient și limitele lasă clientul informat și în control, fără comenzi duplicate accidentale sau schimbări ale plătitorului.
Veți testa calea de succes și cazurile de eșec înainte de a include platforma în publicație.
Unde veți lucra Setări OAuth → Verificare
Utilizați lista de testare la nivel de aplicație și un cont de plată eligibil diferit de Builder. Există cel mult cinci locuri pentru testeri, inclusiv invitațiile în așteptare. Completați verificarea reală a endpoint-urilor și domeniului pentru fiecare platformă inclusă în publicație.
inference sau monetization_gateway și apelul API de plată necesar cu succes pentru payments. O cerere de plată poate fi în așteptare fără debit; un test complet de checkout verifică suplimentar confirmarea explicită și plata.Integrarea dvs. distinge accesul acceptat, termenii acceptați, plata solicitată și plata confirmată și gestionează calea de eșec pentru fiecare.
Selectați contul personal sau organizațional care va deține înscrierea în program înainte de aplicare. Organizațiile pot trimite o aplicație înainte de verificare, dar aprobarea personalului singură nu activează accesul. Finalizați verificarea emailului organizației și a companiei din lista de verificare de onboarding în Console. O organizație aprobată rămâne În așteptarea verificării până când ambele verificări sunt complete. Builder, Provider și Creator programele urmează această regulă.
Vizualizați prețurile Monetization Gateway. · Explorează ShareAI for Startups · Domenii și permisiuni
Termenii și condițiile publice, Politica de confidențialitate și instrucțiunile de ștergere trebuie să corespundă aplicației și să rămână accesibile fără autentificare. Acceptarea programului ShareAI, aprobarea Monetization Gateway, permisiunea OAuth a clientului și contractul de facturare acceptat sunt decizii separate. Reîmprospătarea nu poate adăuga permisiuni sau accepta noi termeni comerciali.
Domeniul vechi surcharge rămâne acceptat pentru integrările existente. Noile exemple utilizează monetization_gateway. Păstrați câmpurile existente, cum ar fi surcharge_bps și surcharge_percentage, neschimbate.
Vizualizați prețurile Monetization Gateway. · Explorează ShareAI for Startups · Domenii și permisiuni
Taxele standard 5% ale Builder markup. Pentru €2.00 din costul rețelei AI și un 10% markup, clientul plătește €2.20. ShareAI primește €0.01 din €0.20 markup; Builder are €0.19 înainte de Event Ingestion.
Primele 1,000 cereri de Producție stabilite Monetization Gateway sunt gratuite în fiecare lună calendaristică (UTC), partajate în contul Builder. Cererile suplimentare costă €0.04 per 1,000 înainte de aplicarea reducerilor eligibile. O cerere stabilită creează un eveniment.
Pay with ShareAI pe cont propriu, inference-acces exclusiv, cheile API ale conturilor obișnuite și traficul de Staging sau testare nu generează Monetization Gateway Ingestie de Evenimente.
ShareAI for Startups oferă o alocație lunară partajată pentru taxele reale ShareAI pe o aplicație aprobată. Nivelurile actuale Launch, Growth și Momentum listează €1,000, €5,000 și €10,000 pe lună. Același buget acoperă taxa procentuală ShareAI pe adaosul Builder și Ingestionarea Evenimentelor facturabile împreună. Nu este o alocație pentru adaos brut, o cotă separată de evenimente gratuite sau inferență AI gratuită inference. Primele 1,000 evenimente gratuite ale contului nu o consumă.
Taxele rămase pentru Ingestionarea Evenimentelor sunt plătite din noile câștiguri ale cererii Builder, apoi din câștigurile AI disponibile Builder și creditele AI nerestricționate. Taxele AI ale clientului și produsul payments rămân separate.
ShareAI poate aproba taxe specifice aplicației sau suport pentru taxe pentru o perioadă fixă sau până la modificare. Revizuiți prețurile actuale ale aplicației și Programele Speciale în Console pentru termenii aprobați, valabilitate și alocația consumată. O schimbare de nivel sau o suprascriere a prețurilor nu resetează utilizarea lunară a aplicației.
Launch păstrează opțional Log in with ShareAI. Growth și Momentum îl necesită; Momentum necesită, de asemenea, insigna oficială ShareAI for Startups în subsolul aplicației. ShareAI verifică săptămânal insigna. Încercările confirmate de a ocoli cerințele pot duce la retrogradare, eliminare din Programul Startup sau retragere din Marketplace conform termenilor programului acceptați.
Tarifele pentru Enterprise sunt configurate de echipa ShareAI pentru contul Builder după ce se ajunge la un acord personalizat. Procentajul atribuit și rata evenimentului se aplică cererilor viitoare.
Vizualizați prețurile Monetization Gateway. · Explorează ShareAI for Startups · Domenii și permisiuni