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

AppleReceiptValidator: .production or .sandbox #132

Closed
yurevich1 opened this issue Jan 30, 2017 · 3 comments
Closed

AppleReceiptValidator: .production or .sandbox #132

yurevich1 opened this issue Jan 30, 2017 · 3 comments

Comments

@yurevich1
Copy link

Please, help me to understand how it works:

in app purchases are 'sandbox'-like even if I use .production in my iPad.
May I always use .production?

Why? I'm confused.

As I know, inside swift code I have to write manually: debug or release code I use.

What happends while using this library?

@ramunasjurgilas
Copy link

In the Apple documentation is written that first of all validation should be checked against production and if it fails with specific error (now I can not remember this error code) it should be checked using sandbox environment.
If you will use .production value it will be done as I wrote.

@ramunasjurgilas
Copy link

One more comment. Receipt validation should not be done on the device. You must to send it to the backend and do validation in the backend. It was mentioned in WWDC 2016 InApp Purchase session.
Receipt validation should be done locally. One way of doing it by using OpenSSL framework.

@bizz84
Copy link
Owner

bizz84 commented Feb 20, 2017

@yurevich1 as @ramunasjurgilas pointed out, you should use the .production mode. SwiftyStoreKit will automatically retry with .sandbox if needed.

Contributions are welcome on local receipt validation.
I'm going to close this issue as this is already tracked here: #101

@bizz84 bizz84 closed this as completed Feb 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants