Post not yet marked as solved
We are planning to ban users who repeat suspected refund abuse.
For judging the refund is abuse or not, we think the cancellation_reason property in ServerNotification helpful.
https://developer.apple.com/documentation/appstoreservernotifications/unified_receipt/latest_receipt_info
cancellation_reason:
The reason for a refunded or revoked transaction. 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
We're thinking to judge the user who refunds many times with cancellation_reason = 0 as suspicious of abuse, and ban.
Question:
Is it OK to use cancellation_reason for such judgement?
How is the property determined? Does it only rely on User's report? Or does the Apple Support make a judgement?
Can you provide a general exsample when cancellation_reason is 0? (We want reply from person inside Apple).
About Identify Refund Abuse:
https://developer.apple.com/documentation/storekit/original_api_for_in-app_purchase/handling_refund_notifications#3591293
Post not yet marked as solved
where is private key of subscription v2, i find everywhere.buy still print
"crypto/ecdsa: verification error"
Question about data format of response body v1 on “Server Notification” (not storekit).
https://developer.apple.com/documentation/appstoreservernotifications/responsebodyv1
We’d like to specify the refunded product or purchase record in our database when receiving the REFUND notification.
We are guessingproduct_id and original_transaction_id in the most-recent latest_receipt_info are the keys for specify that, and we can find most-recent latest_receipt_info by checking the purchase_date.
But we haven’t found official information from apple about that and we can't sure about our guess.
We just found infomation about storekit, but not for server notification.
https://developer.apple.com/documentation/storekit/original_api_for_in-app_purchase/handling_refund_notifications
Does anyone know the official information or actual utilization experience?
What are the rest of the latest_receipt_info array? Why it is designed as array?
Post not yet marked as solved
Hello,
we are currently testing non-renewing subscriptions purchase in new sandbox environment. We would like to receive server notifications but for v2 we only receive notification for auto-renewing subscriptions.
Are notifications for other types of purchases also availible ?
Post not yet marked as solved
Hi, we are moving from server notification from v1 to v2. In server notification v1, we can tell whether a transaction is a trial or not by parsing latest_receipt, is there any way to find out a transaction is a trial or not in v2?
Post not yet marked as solved
I have been testing server to server notifications but I am not sure of getting the following notifications on sandbox. I have enabled the grace period on my app store connect account but how to fall the billing to be failed to renew and test grace period concept. Can any one help me on the actions to be performed for getting following notifications on Sandbox?
1, DID_CHANGE_RENEWAL_STATUS
-> AUTO_RENEW_ENABLED, AUTO_RENEW_DISABLED
2, EXPIRED
-> BILLING_RETRY
3, GRACE_PERIOD_EXPIRED
4, DID_FAIL_TO_RENEW
-> GRACE_PERIOD
5, DID_RECOVER
6, REVOKE
Post not yet marked as solved
Hi, We have auto renewable in app purchases in our application. As per the documentation we have configured Production & Sandbox URLs to receive V2 notifications. Also, created multiple sandbox test accounts to see if notifications can be received? Unfortunately not receiving any of the notifications as mentioned in the documentation to the configured URLs. If any one resolved this issue already, please comment.
My feedback ticket is FB9933934, please help me!
Thanks.
Post not yet marked as solved
I set out app sandbox v2 server notification url ,it is https, but it cannot receive any notification after user subscribed or renewed our product.
How can I ensure that notification is sended, or test the notification is working.
Please help me , thanks
Post not yet marked as solved
Hello All,
Our app implements in app purchase as follows,
The App is free to download and sign up, some features are available if monthly subscription is valid.
We have implemented server side validation (app side validation is not present) so app will perform the in app purchase and forward the receipt, received from App Store, to the server.
This functionality worked so far but recently we noticed that the App Store is sending invalid/expired receipt to the app, which in turn gets forwarded to the server.
Upon checking the receipt data, server finds out the receipt is already expired and so server disables the paid features.
We are trying to figure out process to enable user to resubscribe to the paid feature through app.
Not sure if we missed something but the document we found so far, mentions to block the features or provide grace period to the users but we were not able to locate any document which explains process to enable users to resubscribes.
Any pointer will be helpful.
Validating Receipts:
https://developer.apple.com/documentation/storekit/original_api_for_in-app_purchase/validating_receipts_with_the_app_store
Please let me know if you need any additional help. Thanks in advance.
Post not yet marked as solved
sandbox env, after a sub product auto stop autorenew, customer renewed a subscription interactively by using our app’s interface. I am using Apple's server-to-server notification. our server receive event as follows: DID_CHANGE_RENEWAL_STATUS autorenewstatus =1; INTERACTIVE_RENEWAL;DID_CHANGE_RENEWAL_STATUS autorenewstatus =0. i am confused about why autorenewstatus=0 comes after INTERACTIVE_RENEWAL event automatically.
Post not yet marked as solved
I'm developing an API to receive App Store server notifications for App Store subscriptions and am testing it in my dev environment using the sandbox function.
One thing I want to verify is the notification retry mechanism as per this piece of documentation:
https://developer.apple.com/documentation/appstoreservernotifications/responding_to_app_store_server_notifications.
I recently returned some non-200 responses to some notification requests and expected to see retries of those requests (the docs state retries at 1, 12, 24, 48, and 72 hours for v2 notifications).
However, 12 hours later I haven't a single retry.
Should I expect retries in the sandbox environment?
I'm reticent to go live until I can confirm retries work as advertised and I understand their behaviour.
Kind regards
Dan Poxton
Post not yet marked as solved
Hey,
We're attempting to implement subscriptions in an app we're working on but we're having issues with App Store Server Notifications, specifically, we aren't receiving them, there aren't even any hits to the URL in our server logs.
On the app side of things the purchases are all going through fine.
I've seen a few other devs here mention that the server needs to be compatible with ATS - is there an easy way of checking this?
The same site / server runs the backend for our app and is fully accessible via our API endpoints there, so that would lead me to believe the server is ATS compatible.
Any help would be greatly appreciated!
Thanks!
Post not yet marked as solved
I made a purchase of consumables in a sandbox environment, but I did not receive any alert. 😥
Doesn't the purchase of consumables send an alarm?
Can I get an alert only for refunds?
Post not yet marked as solved
We just started receiving server notifications a day ago and detected a number of them missing the unified_receipt field. They're all subscription related notifications and without that field it is not possible to track down which transaction the notification is related to. Is this a bug?
Post not yet marked as solved
I've noticed that the server we've created to handle the notifications received from apple serve-to-server notifications have been sent in a couple of days at time.
Exemple: Apple sent a notification INITIAL_BUY type at 01/28/2022. At 01/29/2022, apple sent another two INITIAL_BUY notifications, with the same originalTransactionId and trasactionId. As the server is not expecting to receive another INITIAL_BUY, it has been returning 5xx for Apple. For this same consumer, I've received another five notifications with INITIAL_BUY, all of them with the same trasactionId. Futhermore, I've received another notifications that were repeated and with the previous transactionId from the INITIAL_BUY...
We're having problems with the Sandbox Server URL for the App Store Server Notifications. Unfortunately, we're not getting any callbacks from Apple Server while making in app purchase.
We examined the URL endpoint and verified that it complies with Apple's guidelines, as well as appropriately configuring it.
Ref. https://help.apple.com/app-store-connect/#/dev0067a330b
Post not yet marked as solved
Can we safely assume that App Store server notifications will originate from 17.0.0.0/8 address block?
More specifically, does the Technical Note TN2265 - https://developer.apple.com/library/ios/technotes/tn2265/_index.html#//apple_ref/doc/uid/DTS40010376-CH1-TNTAG41 about push notifications also apply for App Store server-to-server notifications?
The IP address range for the push service is subject to change [...] However, the entire 17.0.0.0/8 address block is assigned to Apple, so you can specify that range in your firewall rules
Post not yet marked as solved
We've trying to integrate server-server communication implemented for in-app purchases. During the process of testing we're facing issues which I believe its something to do with JWT creation.
Is anyone faced this error response: https://developer.apple.com/documentation/appstoreserverapi/invalidappidentifiererror when you try https://developer.apple.com/documentation/appstoreserverapi/get_all_subscription_statuses?changes=latest_major
Any feedback or help would be appreciated.
We've followed the setup and JWT generation as per this: https://developer.apple.com/documentation/appstoreserverapi/generating_tokens_for_api_requests?changes=latest_major
Thanks!
Post not yet marked as solved
I find in document https://help.apple.com/app-store-connect/#/devb57be10e7
Last sentence in tip2's paragraph 2.
"See Add an in-app purchase to use App Store Connect to add your in-app purchase, or App Metadata Specifications to use XML."
So, Apple only supports creating product by XML or Manually(App Store Connect) ?
Is there any good practice for Live stream subscriptions?(Every streamer could be subscibed, and every one could be a steamer, that means the auto-renew subscripion products could be many and dynamically)?
Hello! I want to parse json, which you send in notifications v2, but have some questions about required and optional fields (actually I may do all the fields, which are non obvious for me optional, but that's not suitable).
It would be really amazing if you will update your docs with this info! And it would be cool if you'll add some examples of the whole notification structure (it would be more convinient) with different types (and refer to example for concrete field like here is "revocationDate", it appears in case of "REVOKE" event and may be found here: <example reference> - it would be perfect!)
Main questions are:
does signedRenewalInfo always appear here or it doesn't if it's consumable notification?
does bundleId either always appear or it may not if it is deleted somewhere somehow?
do i understand right that "empty subtype" doesn't mean empty string but means absence of field in json?
does autoRenewStatus always appear here or it may be absent?
do purchaseDate and originalPurchaseDate from here always appear or there are some cases (revocation maybe) when they may be missed?
does transactionId field always appear or there are some exceptions (revocation?)?
does inAppOwnershipType from here always appear?
is quantity (from the same struct) required field?
is webOrderLineItemId (from the same struct) a required field?
saka11.