Post

Replies

Boosts

Views

Activity

Reply to Unable to reply to a question to the forum
Hello Eskimo. I apologize for the delay in replying, but I don't usually visit the forum. I posted another comment today, and when I checked my profile I saw that there were answers to this question. Today I went back to the URL where I didn't have the reply button, and I still don't have it. In this thread, as is evident, I have been able to. In other places where I comment I'm used to receive email notifications when there is a reply, and then I go the the forum to read it. As you suggester, I filed a bug, and the URL is: https://feedbackassistant.apple.com/feedback/9062922 Thanks a lot for your answer.
Mar ’21
Reply to How to test server-to-server (S2S) notifications
Hello! Has anyone know of any tool to generate mocked notifications that can be sent (in the right order, at different moments) to the URL that handles the notification, in order to test that our code behaves as expected? Having I integrated the Google notifications in our system (where you can test all the notifications), I'm unpleasantly surprised that Apple system doesn't allow to test all the possible notifications in Sandbox, and that the order of sent notifications isn't the expected one (as I told in the previous message). Due to the fact that some notifications can't be generated in the Sandbox, I don't have a complete collections of notifications that let us to test our code. Does anybody know how to get such a test collection?
Apr ’21
Reply to Cancel server notification with no cancellation_date_ms
I don't know the actual reason, because the documentation about notifications is incomplete, confusing and changing... I don't know if the cancellation_date appears when CANCEL means a refund (of a auto-renewing subscription). But this is just an idea, in case this gives you a clue. In Handling Subscriptions Billing it - https://developer.apple.com/documentation/storekit/in-app_purchase/subscriptions_and_offers/handling_subscriptions_billing#3221919 it says: Detect a Refund Users pay for a subscription when they purchase it, and they can receive a refund by contacting Apple customer service. For example, if the user accidentally buys the wrong product and requests a refund, customer support can cancel the subscription and issue a full or partial refund. Customers may cancel a subscription in the middle of a subscription period, but the subscription remains paid through the end of the same period. Additionally, users may also receive a refund when they upgrade their subscription to another subscription product at a higher level in the same subscription group. To identify whether a subscription has been refunded, look for the cancellation_date field in the receipt. The App Store notifies your server of refunds with a status update notification of type CANCEL, at which point you can handle the refund. For example, if the user upgraded the subscription, immediately unlock service for the higher level subscription product purchased. But I'm not sure of anything about notifications... They are a actual mess... I've found several articles writing about the uselessness of server-to-server notifications (recreate the URL from this fragments, deleting spaces and End-Of-Line chars, that I can't post URLs): https://www. revenuecat.com/blog/apple-subscription-notifications-are-almost-useless https:// blog.apphud.com/subscriptions-notifications/
Apr ’21
Reply to About App Store Server Notifications
At the bottom of https://developer.apple.com/documentation/appstoreservernotifications there is a link "Your Server. Specify your secure server’s URL in App Store Connect" that points to https://developer.apple.com/documentation/appstoreservernotifications/your_server In the Discussion section, there is a linked text: See Enter a URL for App Store Server Notifications for instructions. that point to https://help.apple.com/app-store-connect/#/dev0067a330b where you can see where you should enter the URL. The image is: https://help.apple.com/app-store-connect/en.lproj/GlobalArt/Subscription_Status_URL.png Perhaps you should browse the previous sections, in the left pane.
Apr ’21
Reply to How to properly parse unified_receipt
Perhaps this sample code can help you: https://developer.apple.com/documentation/storekit/in-app_purchase/subscriptions_and_offers/determining_service_entitlement_on_the_server (This appears linked in one of the URLs below) https:// github.com/paulw11/subscription-monitor Some other links from WWDC2020 with explanations about server-to-server notifications Architecting for subscriptions https:// developer.apple.com/videos/play/wwdc2020/10671 Engineering Subscriptions https:// developer.apple.com/videos/play/wwdc2018/705/ What’s new with in-app purchase https:// developer.apple.com/videos/play/wwdc2020/10661 Note: It seems incredible for me that I can't include links to Apple websites... I've have had to break URLs in order to be able to send this message... You'll have to recreate the original URLs from its fragmentsç Additional ones related to server-to-server notifications: Introducing StoreKit Testing in Xcode https:// developer.apple.com/videos/play/wwdc2020/10659 Subscription Offers Best Practices https:// developer.apple.com/videos/play/wwdc2019/305/ In-App Purchases and Using Server-to-Server Notifications https:// developer.apple.com/videos/play/wwdc2019/302/
Apr ’21
Reply to IAP - Auto Renewing Subs + S2S Notifications
The field you should use is original_transaction_id, not transaction_id. That's the value you should use when receiving notifications to search in your database in order to identify the user related to that original_transaction_id. When the use makes is initial purchase from the app, you have to send the user ID and the original_transaction_id to your server, and save that information in the database. When the INITIAL_BUY happens "outside the app", you will not have the information about the user, so you'll have to go to the app to recover the receipt and its original_transaction_id to be able to make the relation between the user ID and the original_transaction_id.
Apr ’21
Reply to Cancel server notification with no cancellation_date_ms
Additional information (such as it appears today 20210405): In https://developer.apple.com/documentation/appstoreservernotifications/unified_receipt/latest_receipt_info it says: Properties cancellation_date string The time when Apple customer support canceled a transaction, in a date-time format similar to the ISO 8601. This field is only present for refunded transactions. cancellation_date_ms string The time when Apple customer support canceled a transaction, or the time when the user upgraded an auto-renewable subscription plan, in UNIX epoch time format, in milliseconds. This field is only present for refunded transactions. Use this time format for processing dates. For more information, see cancellation_date_ms. cancellation_date_pst string The time when Apple customer support canceled a transaction, in the Pacific Time zone. This field is only present for refunded transactions. cancellation_reason string The reason for a refunded transaction. When a customer cancels a transaction, the App Store gives them a refund and provides a value for this key. A value of “1” indicates that the customer canceled their transaction due to an actual or perceived issue within your app. A value of “0” indicates that the transaction was canceled for another reason; for example, if the customer made the purchase accidentally. Possible values: 1, 0 So those fields would be expected only when there was a refund.
Apr ’21
Reply to what's the type of expiration_intent in server notification's response body
This is a fragment of one notification (redacted) I've receive "pending_renewal_info" : [ { "auto_renew_product_id" : "XXXXXXX0001", "auto_renew_status" : "0", "expiration_intent" : "1", "is_in_billing_retry_period" : "0", "original_transaction_id" : "1000000XXXXXXX924", "product_id" : "XXXXXXX0001" }, { "auto_renew_product_id" : "XXXXXXX00000001BR", "auto_renew_status" : "1", "original_transaction_id" : "1000000XXXXXXX939", "product_id" : "XXXXXXX00000001BR" } ], As you can see, it is a numeric value (1 in this case) expresed as a string ("1").
Apr ’21
Reply to Matching original_transaction_id to subscriber id.
Hello, ajhank2. In English: Since in server notifications Apple does not send data that allows you to relate a user to the notification received, when you receive a notification of an initial purchase (INITIAL_BUY) you will not know which user it corresponds to. When you receive the INITIAL_BUY notification you should save the record in your database, waiting to be able to relate it later with a user. To obtain that information you would have to ask the user to connect to the app, retrieve the receipt and the original_transaction_id related to that purchase, send it to the backend server along with the user's ID in your system (logged in the app), so that it executes the call to the verifyReceipt URL using the receipt (obtained from the app). In the value returned by verifyReceipt you should have that original_transaction_id (which confirms the validity of the receipt) and on the server you can now link the values of original_transaction_id and the user ID. The next notifications you receive with the renewals will arrive with the original_transaction_id, which you will already have linked in your database with a user, so you have no problem to know who they correspond to. If you let the subscriptions expire, from the app you can resubscribe and the same original_transaction_id that was generated in the first purchase will be used. If you go more than 180 days without renewing any subscription, the next time you buy you will receive another INITIAL_BUY notification, and you will be in the same case again. In our case it is normal that the first purchase is made in the app, so at that moment, when we have the receipt, the original_transaction_id and the user ID, in the call to our backend (API Gateway in AWS), is when we make the data binding, so that the following notifications we have all the data we need. In Spanish: Dado que en las notificaciones de servidor Apple no envía datos que permitan relacionar un usuario con la notificación recibida, cuando recibes una notificación de la una compra inicial (INITIAL_BUY) no sabrás a qué usuario corresponde. Cuando te llegue la notificación INITIAL_BUY deberías guardar el registro en tu base de datos, a la espera de poder relacionarla posteriormente con un usuario. Para obtener esa información tendrías que pedirle al usuario que se conectara a la app, recuperar en ella el receipt y el original_transaction_id relacionado con esa compra, enviarla al servidor de backend junto con el ID del usuario en tu sistema (logado en la app), para que este ejecute la llamada a la URL de verifyReceipt con usando el receipt (obtenido de la app). En el valor devuelto por verifyReceipt deberias tener ese original_transaction_id (lo que confirma la validez del receipt) y en el servidor ya puedes vincular los valores de original_transaction_id y el ID del usuario. Las siguientes notificaciones que te lleguen con las renovaciones llegarán con el original_transaction_id, que ya tendrás vinculado en tu base de datos con un usuario, con lo que no tienes problema para saber a quién corresponden. Si dejas que las suscripciones caduquen, desde la app puedes resuscribirte y se usará el mismo original_transaction_id que se generó en la primera compra. Si estás más de 180 días sin renovar ninguna suscripción, la proxima vez que compres se recibirá otra notificación INITIAL_BUY, y volverás a estar en el mismo caso. En nuestro caso lo normal es que la primera compra se haga en la app, por lo que en ese momento, en el que tenemos el receipt, el original_transaction_id y el ID del usuario, en la llamada a nuestro backend (API Gateway en AWS), es cuando hacemos la vinculación de los datos, para que las siguientes notificaciones tengamos todos los datos que necesitaremos. Kind regards, Oscar
Apr ’21
Reply to When does Apple send the "INTERACTIVE_RENEWAL" Subscription Notification?
Rich, is it possible that INTERACTIVE_RENEWAL is sent when the change in the subscription is to be applied instantly, and that DID_CHANGE_RENEWAL_PREF is sent when the change is to be made at the end of the current subscription? Perhaps these article in RevenueCat.com can be relevant (you'll have to reconstruct the URLs from fragments, that I can't post it in the right way): https:// www. revenuecat.com/blog/ios-subscription-groups-explained https:// www. revenuecat.com/blog/apple-subscription-notifications-are-almost-useless
Apr ’21