Non-Sub Consumable Metadata

Question

Hey! I’m exploring a system in my app where users can either pay a one-time fee to unlock a single specific article in a news app, or subscribe (monthly) to unlock all articles in the app.

The subscription is easy. Product => Entitlement, check for the entitlement, badaboom, done.

I am however not 100% sure on the best way to “unlock a single article”.

I understand how to trigger the purchase, and I understand I need to implement a webhook against NON_RENEWING_PURCHASE to confirm receipt. What I’ve yet to nail down is the method in which my server knows which article to unlock.

Is there a way to attach any form of metadata in the purchase? (`article: 123456`). I can’t seem to spot it.

Alternatively, is the flow to have the app itself (after the purchase goes through) call an “unlock” API on my server with transactionId and article ID, which then looks for a corresponding webhook?

With this flow, how would folks recommend handling the race condition between the webhook (which per docs can take in excess of 60s, though often much quicker) vs the purchase confirmation (which is very quick).

Is the third option to skip the webhook entirely and use the REST API? iOS SDK confirms purchase, calls my API with the transactionId and article ID, my API queries RevenueCat to confirm purchase, then unlocks the content? (Will RevenueCat always have the transaction before purchase callback is called?)

Any and all insights are very much appreciated! Thanks

(Note: I have for the purpose of discussion simplified the actual product, it’s not articles… but it’s easier to discuss when we all understand the proposition!)

hussain · Accepted Answer

Hi ​@jamessherlock,Thanks for reaching out. I’m happy to help.As of today there isn't a generally available way to attach arbitrary metadata to an iOS in-app purchase that gets propagated through to theNON_RENEWING_PURCHASEwebhook today. So options 2 and 3 are where you want to focus. I'd push you toward your third option (REST API verification) as the primary path, with the webhook as a reconciliation safety net.Here's how I'd structure it:User taps "Unlock article 123456" ->SDK kicks off the StoreKit purchase.When the SDK's purchase completion fires successfully, the app POSTs{ app_user_id, article_id, store_transaction_id }to your backend.Your backend callsGET /v1/subscribers/{app_user_id}and looks for thatstore_transaction_id(or the corresponding RevenueCat-assignedid) inside thenon_subscriptionsmap for the right product identifier.If it's there, persist(article_id, transaction_id, user_id)in your DB and grant access. If not, return a soft error and let the app retry with backoff.Some things to keep in mind:Refunds:listen forCANCELLATION/refund events and revoke article access in your DB. This is the big one.Server-driven reconciliation: a nightly job that confirms every unlock has a corresponding RC transaction.Hope this helps, let me know if you have any other questions.Best,Hussain

hussain · Answer

Hey ​@jamessherlock,I’m glad I was able to help.Now coming back to your question. In practice it's rare. The iOS SDK's purchase completion only firesafterthe receipt has been posted to our backend and verified with Apple, so by the time your app sees success, the transaction is almost always already on file with us.The cases where it isn't usually come down to brief cache propagation, or a flaky network delaying the receipt post.So I'd build step 4 to be forgiving rather than assume strict consistency:If thestore_transaction_idisn't innon_subscriptionson the first call, retry with exponential backoff (1s, 2s, 4s.3 attempts is plenty).If it still isn't there, fall back to the webhook as the reconciliation path.That combo covers essentially every case without making the user wait on webhook latency.Hope this helps, let me know if you have any other questions.Best,Hussain

Sign up

‏‏‎ ‎

Log in to the Community

‏‏‎ ‎

Scanning file for viruses.

This file cannot be downloaded