Zevron for apps
You sell on the web now. Chargebacks on those sales are yours to win.
Zevron answers web chargebacks with your in-app logs, answers Apple’s refund requests inside its 12 hours, and recovers failed web renewals. One bundle, paid on results.
First 10 disputes free · then 15% of disputes won, 12% of renewals recovered · nothing when we lose
Web billing on Stripe, iPhone users on the App Store, events from your own server
- Stripe
- App Store
- RevenueCat
- Visa CE 3.0
- Mastercard
- American Express
- session_start
- login
- feature_used
- purchase
- terms_accepted
- consumption_consent
- consumption_consent_withdrawn
- Swift
- Kotlin
- React Native
- Web
- Express relay
Chargeback defense for apps that sell on the web. Your app’s own logs in front of the bank, Apple answered on time, renewals recovered.
Proof from your app
Sessions, lessons and purchases, each with the device and IP, sent from your server.
Matched to earlier payments
On a fraud claim we check Visa CE 3.0: the same device and IP on earlier, undisputed payments.
Apple answered in time
Refund requests answered inside Apple's 12 hours, only for customers who agreed.
From the first session to the answer. One customer, five moments, all from data you already have.
- session_start8:02 am
- feature_used · lesson8:04 am
- feature_used · lesson8:19 am
Why this matters now. A sale on your website is yours to defend.
As of April 2026, apps in the United States can link customers to an outside payment page instead of selling only through Apple's in-app purchase. Apple charges a fee on those linked purchases, and a court has found that fee too high. Which fee is allowed is still being fought: Apple has said it plans to ask the Supreme Court to review the case.
However that ends, a purchase made on your website is yours to defend. You are the seller, the card is charged by your processor, and a chargeback lands in your account and counts toward your dispute ratio. Apple's refund process does not cover it.
- Source: TechCrunch, April 6, 2026: Apple and Epic Games, the Supreme Court appeal and the App Store commission. Reviewed October 2026.
- This is a summary, not legal advice. The rules differ outside the United States and are changing. Check Apple's current guidelines and talk to your lawyer before you change how you sell.
Payment record only
- A card number ending in four digits
- An amount and a date
- A billing address
With your in-app logs
- The same device and IP on two earlier, undisputed payments
- Sessions and lessons after the charge
- The terms accepted at checkout, with the time
Your app is the only place that knows the customer came back. Zevron puts it in front of the bank in the form the bank reads.
One bundle, three jobs. Paid only on what comes back.
Read the setup guideWeb chargebacks answered with your in-app logs, and Visa CE 3.0 checked on every fraud claim.
Web disputes15% of winsApple's refund requests answered inside its 12 hours, only for customers who agreed.
App StoreConsent firstFailed web renewals retried by decline reason, with a reminder and a card-update link.
Recovery12% of the gainYour server sends the events. The key never ships inside the app.
SetupAn afternoonWe read disputes, charges and invoices. We never move money or change a price.
AccessEvidence only
Set up in an afternoon. Your server sends the events. We do the rest.
- 1Sign up and connect web billingConnect the Stripe account your web checkout charges through. We read disputes, charges and invoices, and submit the evidence you approve. We never move money or change a price.
- 2Send events from your serverA line for each login, session and purchase, with the customer's IP and device. Your server adds them; the key never goes in the app.
- 3Connect the App Store for iOS usersOptional. An App Store Server API key lets us answer Apple's refund requests inside its 12 hours, when your customer agreed to share usage data.
- 4We take it from thereWeb chargebacks are answered with the evidence, a person reviews what needs it, and failed renewals get a second chance. Each part has a green light on your setup page.
What your server sends. Start with session_start, feature_used and purchase. Each carries the customer, their IP and a device ID, so it is one small call from the route that already handles your sessions.
The guide has the whole list, a relay for Express, and code for Swift, Kotlin, React Native and the web.
Open the setup guidecurl -X POST https://zevron.ai/api/v1/events \
-H "Authorization: Bearer $ZEVRON_KEY" \
-H "Content-Type: application/json" \
-d '{
"id": "test_1",
"email": "[email protected]",
"user_id": "6f1c2a9e-3b0d-4e55-9a7f-2d8c1b4e7a10",
"event": "session_start",
"ip": "203.0.113.7",
"device_id": "d_91",
"properties": { "app_account_token": "6f1c2a9e-3b0d-4e55-9a7f-2d8c1b4e7a10", "platform": "ios" }
}'Our win rate on web disputes for apps. Counted, not claimed.
Published from the cases we have actually decided, with the count and the method. If there are too few to say anything, this says so.
0 of 30 decided so far, from 0 of 3 apps.
How typical cases run. One for each part of the bundle.
Example, not a customer
A language app on annual plans
A $89.99 yearly renewal is disputed as fraud. The cardholder has paid on the web twice before without a problem, and has not opened the app since the spring.
The evidence
- Two earlier undisputed payments, about 4 and 8 months before, from the same device and IP
- Lessons completed on that device after the first payment
- The terms accepted at checkout and the reminder email sent before the renewal
What happens
- The chargeback arrives in Stripe and in Zevron.
- Compelling Evidence 3.0 matches the device and IP across the earlier payments.
- A person checks the response before it is filed.
Example, not a customer
A fitness app with iPhone users
Apple asks whether to grant a refund on an annual plan bought from the iPhone six weeks ago. The member has opened the app on 31 days since.
The evidence
- Sessions on 31 of 42 days since the purchase
- A consent record from the member's own acceptance of the data terms
- A refund preference of "decline", stated from the usage
What happens
- Apple's request reaches Zevron by notification.
- The usage events for that appAccountToken are read, and the consent is checked.
- The answer is sent in minutes, well inside Apple's 12 hours.
Example, not a customer
An AI app with a monthly plan
A monthly renewal on the web fails with an insufficient-funds decline. Left alone, the customer would lapse and many would not come back.
The evidence
- The decline code, which says to retry in a few days and not at once
- A card-update link in the reminder, branded as the app
- A comparison group, so the fee is charged only on the gain
What happens
- The failure arrives from Stripe.
- A retry is timed for this kind of decline, inside the networks' limits.
- If it recovers, the plan continues and the fee line appears on the invoice.
We only win when you do. Two rates on money we bring back. Nothing up front, nothing when we lose.
15% and 12% of what we win and recover. First 10 disputes free.
- Web chargebacks won 15%
- of what you get back. Your first 10 disputes are free. Nothing when we lose.
- App Store refund requests declined 15%
- of the purchase price, when Apple rules for you. Nothing when it refunds.
- Failed web renewals recovered 12%
- of the payments we recover, measured against a comparison group so you never pay for what Stripe would have recovered anyway.
One invoice a month, three lines. No setup fee, no minimum, no contract. Web chargebacks, App Store refunds, Renewal recovery: three lines on one invoice.
What we will not do. Said plainly, so you can hold us to it.
- File anything for a dispute you have told us not to fight, or without a person checking the cases that need it.
- Send Apple a customer's usage data without a record that the customer agreed.
- Touch your App Store pricing, your products or your payouts. We read disputes, charges and invoices, and submit only the evidence you approve.
- Promise a win rate. We publish the real one below once there are enough decided cases to say anything.
Questions, answered.
Anything else? Email [email protected] and we’ll get back to you.
Reviewed October 2026. Apple’s and the courts’ positions change; check current sources before you rely on any of this.
Why would a web purchase be disputed differently from an App Store one?
With an In-App Purchase, Apple is the seller. It handles the refund, and asks you for consumption information. With a web purchase, you are the seller. The customer can ask their bank for the money back, the bank opens a chargeback with your processor, and you answer it with evidence. That is the work we do.
Can US apps really link to outside payments now?
As of April 2026, apps in the United States can link customers to an outside payment page instead of selling only through Apple's in-app purchase. Apple charges a fee on those linked purchases, and a court has found that fee too high. Which fee is allowed is still being fought: Apple has said it plans to ask the Supreme Court to review the case. What Apple may charge on those purchases is not settled, so we do not take a position on it. We help with what happens after a customer pays you directly.
Do you take Apple's side of it or help me avoid Apple's fee?
Neither. Where you sell is your decision, and so is how you follow Apple's rules. Zevron starts after the sale: it defends disputes on the web, answers Apple's refund questions for the customers who remain on iOS, and recovers failed renewals.
What do I have to send you?
A line for each session and purchase, from your server: the customer's email or ID, their IP and a device ID. The docs page has a table of events and code for Swift, Kotlin, React Native and the web. A good first day is session_start and purchase.
Is it safe to put the key in the app?
No. Keep it on your server. An app that ships a key lets anyone who unpacks it write events for your account. The docs page has a small relay your server runs: the app sends the event to your backend, your backend adds the customer's IP and sends it on.
How do you know which customer is which across the web and iOS?
By two identifiers you already have. A web dispute is matched by the email on the payment. An App Store request is matched by the appAccountToken you set on the purchase. Use one stable ID per account for both and a customer on the web and on iPhone is one record.
What does Apple need before you send it a customer's usage?
The customer's consent. You choose how that is recorded: each customer's own record (the default and the safe one), a statement in your terms that covers everyone, or none. A customer who withdraws is never shared. Nothing is sent without it.
What does it cost?
15% of the chargebacks and App Store refund requests we win, and 12% of the failed renewals we recover above a comparison group. Your first 10 disputes are free. It is one bundle on one invoice.
What is your win rate for apps?
It is published on this page, from the web disputes we have actually filed for apps, with the number of cases and the period, once there are enough decided cases to mean something: at least 30 from at least 3 apps, and no single app more than half of them. Until then the page says what is missing, and shows no figure.
Which web billing do you support?
Stripe, today. If you bill on the web with Paddle or RevenueCat Web Billing, sign up and tell us: those are in early access, we will work your chargebacks from forwarded emails until they open, and we will tell you before anything changes. Apps that use RevenueCat to manage subscriptions can connect it for subscriber history alongside Stripe.
Is this legal advice?
This is a summary, not legal advice. The rules differ outside the United States and are changing. Check Apple's current guidelines and talk to your lawyer before you change how you sell.
Put a number on it with your own data.
Connect Stripe and see what your last year of disputes looked like. The first 10 are on us.