Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SwiftyStoreKit.refreshReceipt() should not be removed #223

Closed
5 of 9 tasks
hlung opened this issue Jun 1, 2017 · 12 comments
Closed
5 of 9 tasks

SwiftyStoreKit.refreshReceipt() should not be removed #223

hlung opened this issue Jun 1, 2017 · 12 comments

Comments

@hlung
Copy link

hlung commented Jun 1, 2017

Platform

  • iOS
  • macOS
  • tvOS

In app purchase type

  • Consumable
  • Non-consumable
  • Auto-Renewable Subscription
  • Non-Renewing Subscription

Environment

  • Sandbox
  • Production

Version

ℹ Please replace this with the version of SwiftyStoreKit you're using.
10.1

Report

This pull request #213 removed SwiftyStoreKit.refreshReceipt(). But I need it for refreshing receipt and send it to my server for validation. I think it is a valid use case.

@vovkaprigarin
Copy link

Yep. I didn't found this method in new version.
Case: If you change apple id - you will need update receipt and after then you will send to my server. I need this function! :)

@bizz84
Copy link
Owner

bizz84 commented Jun 2, 2017

@hlung @vovkasmprigarin Currently, the receipt is refreshed automatically if it's missing when you call verifyReceipt.

The intention is to let SwiftyStoreKit handle this for you.

Rather than restoring the old refreshReceipt() method, I think it would be best to pass a new forceRefresh parameter to verifyReceipt():

verifyReceipt(using validator: ReceiptValidator, 
                       password: String? = nil, 
                       forceReceipt: Bool = false, 
                       completion: @escaping (VerifyReceiptResult) -> Void)

This way, SwiftyStoreKit will first refresh the receipt, then use it with your ReceiptValidator.

Makes sense?

@vovkaprigarin
Copy link

@bizz84 No. I send receipt data to my server for validation.

@hlung
Copy link
Author

hlung commented Jun 2, 2017

@bizz84 Yes it make sense if i let apple validate receipt for me. But my app does validation on server (need to send actual receipt data). Calling SKRefreshReceipt request is troblesome because of the delegate pattern. Having SwiftyStoreKit handle this with callback closure is much easier to use ;)

@bizz84
Copy link
Owner

bizz84 commented Jun 2, 2017

@vovkasmprigarin @hlung If you use AppleReceiptValidator like in the README, then you're validating the receipt with Apple.

However, you don't have to. You can write your own validator that takes the receipt data as a string, and posts it to your own server. Example:

class CustomReceiptValidator: ReceiptValidator {
    func validate(receipt: String, password autoRenewPassword: String?, completion: @escaping (VerifyReceiptResult) -> Void) {
        // encode string, send to your own server, call completion when processed.
    }
}

You can then call validateReceipt() like so:

let customValidator = CustomReceiptValidator()
SwiftyStoreKit.verifyReceipt(using: customValidator, password: "your-shared-secret") { result in
    switch result {
    case .success(let receipt):
        // Verify the purchase of Consumable or NonConsumable
    case .error(let error):
        // Handle error
    }
}

I can add a forceRefresh parameter if needed, but other than this you shouldn't need anything else to do your own custom validation.

@bizz84
Copy link
Owner

bizz84 commented Jun 2, 2017

@vovkasmprigarin I have opened #224 to add a forceRefresh parameter, however I'm not convinced this is necessary.

If you already have a local receipt and you change the Apple ID, are you sure the app doesn't update the receipt automatically?

@bizz84
Copy link
Owner

bizz84 commented Jun 3, 2017

This is now implemented and available on version 0.10.3.

Closing the issue for now. Feel free to ask more questions if needed.

@bizz84 bizz84 closed this as completed Jun 3, 2017
@vovkaprigarin
Copy link

@bizz84 yep. If you change the AppleID, the Receipt doesn't update automatically:(

CustomReceiptValidator send data to apple server to validate. It's not correct for me. I send receiptData to my server, and after then server send receiptData to Apple server for validation.

force update may be will help for people, but will not for me:(

Ok. I will use last pod version with refresh receipt function. Thanks for your answers :)

@bizz84
Copy link
Owner

bizz84 commented Jun 5, 2017

@vovkasmprigarin To clarify, AppleReceiptValidator sends the data to Apple.

I am proposing to write your own custom validator to post data to your server. See my answer above.

@hlung
Copy link
Author

hlung commented Jun 15, 2017

In my case, I need to pass user id to my backend. Since ReceiptValidator protocol doesn't allow me to add custom data, I need to pass user id to my custom validator at instantiation time. Not very clean.

I think I can just create a SKReceiptRefreshRequest wrapper. May be pull some code from InAppReceiptRefreshRequest. Will share my code later. ;)

@vxst
Copy link

vxst commented Jun 17, 2017

We also need to only verify receipt at server, so the old refreshReceipt is much more handy than implement a custom class for that job.

We believe it's a common case. Anyway, why do we need to use a SwiftyStoreKit if everything need to be a new class and delegate? Apple's Storekit will just be fine.

@bizz84
Copy link
Owner

bizz84 commented Jun 19, 2017

@hlung I think passing any custom data to your ReceiptValidator initialiser should be fine, as you could just create it on the fly and pass it to verifyReceipt.

@vxst You own the logic for receipt verification with your server, so it makes sense to implement it in a class and pass it to SwiftyStoreKit.

  • SwiftyStoreKit automatically refreshes the receipt with Apple if needed (you would have to do this yourself with StoreKit).
  • Once the receipt data is available, it then calls your custom validator.

I see that a few people seem confused by this. Is the documentation not clear?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants