Start free
For developers

Paste one URL. Get a green check.

Pick how you sell. Every setup is three steps or fewer, most need no code, and we count revenue from your store’s own signed data. Never guesses.

Start freePick your setup
The 5 setups

How do you sell? Three steps from here.

Using RevenueCat? Pick that one, even on iOS. Otherwise pick where your payments happen.

App Store

  • 3 steps
  • No code
  • No URL change

iOS apps on StoreKit: with their own server, RevenueCat or nothing at all.

  1. Create an In-App Purchase key
    .p8 key + Key ID + Issuer IDgoes into App Store Connect → Users and Access → Integrations → In-App Purchase
    One key works for all your apps.
  2. Paste it with your bundle ID
    Key + bundle IDgoes into AppCut → Integrations → App Store
    We check it with Apple when you save and read the last 30 days straight away.
  3. Only without a notification URL: paste ours
    Notification URLgoes into App Store Connect → your app → App Information → App Store Server Notifications → Version 2
    Apple keeps history only for notifications it sends somewhere. Already have a URL or RevenueCat? Leave it.
How creators get credit

The iOS SDK (three lines, below), or one App Store offer code per creator. A redeemed code arrives signed by Apple.

What we read
What we read from App Store
EventEffect
Subscribed, offer code redeemedFirst commission (pending)
Renewal, upgradeRenewal commission
One-time chargeCommission
Refund, revokeCommission reversed
Free periods, Xcode environmentIgnored

We read your app’s notification history with your key and check every notification against Apple Root CA G3: certificate chain and ES256 signature. The key is stored encrypted and only reads.

Google Play

  • 3 steps
  • SDK token

Android apps on Play Billing: with their own server, RevenueCat or nothing at all.

  1. Add a push subscription to your RTDN topic
    Our push URLgoes into Google Cloud → Pub/Sub → your RTDN topic → Create subscription → Push
    Your own subscription keeps working.
  2. Paste a service-account key
    Service-account JSON + package namegoes into AppCut → Integrations
    Give the account View financial data in Play Console. We check the key with Google when you save.
  3. Pass the SDK token, then send a test.setObfuscatedAccountId(UGCA.appAccountToken)On BillingFlowParams. Then Play Console → Monetization setup → Send test notification.
How creators get credit

The Android SDK keeps the creator’s link or code under a random UUID that Google hands back on every purchase. It also reads the Play Install Referrer.

What we read
What we read from Google Play
EventEffect
Subscription purchasedFirst commission (pending)
Subscription renewed or recoveredRenewal commission
One-time product purchasedCommission
Voided purchaseCommission reversed, fully or partly
Free trials, holds, pauses, cancellationsIgnored

A push is only a hint: every purchase is read back from the Google Play Developer API with your key, so a forged message can’t create money.

RevenueCat

  • 3 steps
  • No code

Apps that sell through RevenueCat. iOS and Android in one go.

  1. Copy your webhook URL
    Webhook URLgoes into AppCut → Integrations
  2. Copy the authorization value
    Authorization valuegoes into right next to the URL
  3. Paste both in RevenueCat and send a test event
    URL + authorizationgoes into RevenueCat → Project → Integrations → Webhooks → New webhook
    Press Send test event. The check turns green.
How creators get credit

Per-creator offer codes (zero code), our SDK with one identify line, or a ugca_code subscriber attribute.

What we read
What we read from RevenueCat
EventEffect
Initial purchase, renewal, trial conversion, one-off purchaseCommission (pending)
Trial startRecords who brought the user, no money
Refund (cancellation by customer support)Commission reversed
Refund reversedCommission reinstated
Sandbox eventsTest ledger

Every RevenueCat event id is processed once, so retries are safe.

Stripe

  • 3 steps
  • One script tag

Web sales: Payment Links, Checkout, subscriptions, web-to-app.

  1. Create a restricted key
    Stripe → Developers → API keys → Create restricted key
    Read: Checkout Sessions, Invoices, Charges, Customers, Subscriptions, Disputes. Write: Webhook Endpoints. Everything else: None.
  2. Paste it in AppCut
    rk_live_… or rk_test_…goes into AppCut → Integrations
    We create the webhook endpoint in your Stripe account. You copy nothing back.
  3. Add one script tag and buy something<script src="https://<our app>/ugca.js" defer></script>In the <head> of pages with a Payment Link. Green check on the first event.
How creators get credit

The script adds the creator’s click or code to every Payment Link, Buy Button and Pricing Table. Own Checkout Sessions: pass ugca.ref() as client_reference_id. Or a Stripe promotion code per creator.

What we read
What we read from Stripe
EventEffect
Checkout session completedRecords who brought the customer
Invoice paid (first, then each cycle)Commission (pending)
Charge refundedReduced by the refunded amount
Dispute closedLost: reversed. Won: reinstated
Test mode eventsTest ledger

We check the Stripe-Signature on every request (HMAC-SHA256, 5-minute tolerance). The script makes no network calls.

Own backend

  • 3 steps
  • Server-side

Your own billing: StoreKit or Play Billing on your server, Paddle, anything else. Or a relay like Zapier or Make.

  1. Get a test key
    key_id + signing secretgoes into AppCut → Integrations → API keys
    Test keys always write to the test ledger.
  2. Sign and send eventsClaims (“this user came via creator X”) and transactions (“this user paid, or got a refund”), signed with HMAC.
  3. Validate until green, then go livePOST /v1/conversions/validateA dry run: same checks, nothing stored. Send one test chain (claim → initial → refund) and we switch on your live key.
How creators get credit

You send a claim with the creator’s code or click id from your own signup flow.

What we read
What we read from Own backend
EventEffect
ClaimWho brought the user
Initial, renewal, purchaseCommission (pending)
Refund, chargebackCommission reversed
Refund reversedCommission reinstated
Net confirmedCommission corrected to the final net

HMAC-SHA256 over timestamp + body, 5-minute window, idempotent on brand_event_id. Users are pseudonyms: no email, phone or name.

iOS SDK

Links that survive the install. Three lines.

Optional. Add it when you want creator links to carry through the App Store, or a code field in your app.

iOS · Swift
import UGCA

// 1. App start
UGCA.configure(publishableKey: "ugca_pk_live_…")

// 2. Every opened link (universal link or URL scheme)
.onOpenURL { UGCA.handle($0) }

// 3. Every purchase
try await product.purchase(options: [.appAccountToken(UGCA.appAccountToken)])
With RevenueCat
// RevenueCat apps: skip step 3, add this after logIn / configure
UGCA.identify(revenueCatAppUserID: Purchases.shared.appUserID)
Code field
// Optional: "Got a creator code?" + Apply, for onboarding or the paywall
UGCACodeField()
  • Swift Package, product UGCA, iOS 15+.
  • Reports who brought the user, never money.
  • Works offline. Retries are harmless.
  • Android (Kotlin) and React Native / Expo use the same API.
Conversions API

Your own backend? Send us two kinds of events.

Claims say who brought a user. Transactions say what they paid, or got back. Signed, idempotent, JSON only. There’s an OpenAPI 3.1 spec, so you can generate a client.

Endpoints
CallWhat it does
POST /v1/conversions/claimsOne claim: this user came via creator X
POST /v1/conversions/transactionsOne transaction: initial, renewal, purchase, refund, chargeback…
POST /v1/conversions/batchUp to 100 claims and transactions, a result per event
POST /v1/conversions/validateDry run: same checks, nothing stored
GET /v1/conversions/events/{brand_event_id}Status of an event and what it did to the ledger
GET /v1/creators/codesYour creators’ codes, to sync a code field
Sign every request
X-UGCA-Key:        ugca_test_k_…
X-UGCA-Timestamp:  <unix seconds>
X-UGCA-Signature:  v1=<hex( HMAC-SHA256( signing_secret, timestamp + "." + raw_body ) )>
A claim
POST /v1/conversions/claims
{
  "brand_event_id": "claim:hh_9f2c…",
  "external_user_ref": "hh_9f2c…",
  "creator_code": "maya",
  "touch": "typed_code",
  "touched_at": "2026-11-02T10:14:00Z"
}
Responses
202 acceptedStored. Attribution follows.
200 duplicateSame brand_event_id, same body. Nothing done, safe to retry.
409 idempotency_conflictSame brand_event_id, different body.
400 schema_errorA field is missing or wrong. The response names it.
401 invalid_signatureAlso timestamp_skew (over 5 minutes) and unknown_key.
422 unknown_creator_codeNo such code, or it’s paused. Logged as unattributed.
429 rate_limitedOver 50 requests a second per key. Honour Retry-After.
Security and trust

We only pay on what we can prove.

  • Signed store data

    Apple notifications are verified to Apple’s root certificate. Google purchases are read back from the Play Developer API. Stripe and our own API are HMAC-signed. RevenueCat sends a per-app secret.

  • No fingerprinting

    The SDK uses one random UUID per install. No IDFA, no device fingerprint, no third-party calls. ugca.js makes no network calls at all.

  • No personal data

    Users are pseudonyms: a random token, a RevenueCat id or your own hash. Never an email address, phone number or name.

  • Money only from proof

    The SDK reports who brought a user, never money. Commission comes only from verified store and payment events.

  • Test and live never mix

    Sandbox, TestFlight, license testers, rk_test_ keys and test API keys all land in a separate test ledger.

  • Retries are free

    Every event id is processed once. Webhooks can redeliver and your server can retry without double-paying anyone.

Green check today. Creators tomorrow.

Create a brand account, pick your setup and send one test event. No sales call needed.

Start free