Actually I have implemented auto-renewable subscription feature using In-App Purchase on my project.
It throws payment cancelled when I try adding card whilst subscribing. If card is already added, it is working fine.
But App store shows subscription and payment done.
I have used SwiftyStoreKit library which is no longer maintained from May 1.
I have tested all in production mode by downloading app from app store.
Is there any way to test it while development? In sandbox mode, there is no option to test by adding card or paypal.
No,
there is no option to test it while in development. It might be possible to simulate the exact same scenario, but with "parental permissions" - create IAP product that requires parental permissions, and make sure your account is "child" or "limited" - it should have similar flow like expired credit card. Although I have not tested it, but worth a shot.
what happens is that if you add new transaction to the transaction queue, and credit card has expired, you will get "transaction failed" in your queue. If user then fills out the correct credit card, you will get "transaction succeeded" message.
https://forums.developer.apple.com/thread/6431
here you can read more about credit card expiration.
Related
Ok, I suspect the answer to this is simple. But here goes...
I am in the process of submitting my app. I am submitting for review even though my In-App purchase integration has not been tested. This is essentially because I am unable to retrieve my list of IAP items if the IAP items have not been submitted/verified. So it seems to me this is like a "chicken or the egg" kind of situation.
My plan is to submit the App and the 1st IAP item. Then I am assuming this will allow me to magically retrieve the IAP item when I run the App.
Am I approaching this correctly, or is there a more intuitive/simpler way to test the IAP retrieval process (and the many other things to test once it is retrieved)?
Per Apple's Documentation:
To perform testing for in-app purchase products Set up test user
accounts within Users and Roles in iTunes Connect, as detailed in
Creating Sandbox Tester Accounts in iTunes Connect Developer Guide.
You’ll need a test user for each territory you want to test the app
in.
Clear any account information stored on your test device.
In Settings, go to the Store settings. Click the Sign Out button. This
prevents an actual user account from automatically being used when
testing.
Important: Don’t enter your test account information in the Store
settings panel. Doing so may invalidate your test account. Connect
your test device to your Mac.
In Xcode, set your test device as your scheme’s destination.
Open your app, and perform your in-app purchase product testing.
Use your test account credentials to test the purchase.
When your app uses the Store Kit API to request a payment, you’re
asked to sign in. Select Use Existing Account and enter your test
account user name and password. You are then asked to confirm the
purchase. The transaction completes.
No financial transaction takes place, but a receipt is generated for a
successful transaction.
It's pretty straightforward, just takes a bit of set up. Good luck!
I'll be submitting my app to Apple for review at the end of the week. The app is a marketplace platform so users need to enter a credit card when creating an order.
In order for Apple to test the app I assume they need to go through every screen but a credit card is needed for to get to most of them. I'm using Stripe for payment processing and have a dummy card I use for testing, but when I switch to the live environment I don't think the dummy card works any more so how can I allow apple to test it?
I can't figure out how I can submit a production ready app with live API keys and let apple test without processing a real order and charging a real card.
I am implementing auto-renewable subscriptions in iOS and want to be able to test the scenario where the user cancels the subscription but I am unable to do so because when I try to manage subscriptions with the sandbox account the app store wants me to associate a payment method with the sandbox account but in my experience once I do that the sandbox account is no longer valid.
Is it even possible to test cancellations or do I just blindly code for cancellations? I have search high and low and have not found anyone who has been able to manage subscriptions in a sandboxed environment.
I realized today that I was thinking about this all wrong and I can see why its not as necessary to be able to manage subscriptions. I was thinking that the 'Cancellation Date' field would reflect when a user cancel's (or really just opts out of auto-renewing) their subscription. But I was mistaken this field is only for the times when a user contacts Apple Support and requests to cancel early and receive some sort of a refund, and this is not something that is managed directly by a user.
Have you tried using a TestFlight build? You can do sandbox IAP testing via TestFlight with a "normal" iTunes account that has a payment method. I would assume that means you could try out canceling the subscription.
We currently have an app in the app store that uses IAP to disable ads and add a few features.
However, we've noticed that some users have problems buying the IAP. After scrutiny it seems most of it comes down to not having an active internet connection on the moment of purchase. About a dozen cases however could not be tracked down and resolved.
One of these:
tap buy IAP
Credit Card security code was not yet filled in
purchase fails
user is automatically moved to his App Store account to fill in the missing code
user fills in code and confirms buying the IAP
user goes back to the app
purchase is still failed (!)
Conclusion: user paid and did not yet receive the IAP.
(of course this can be resolved by tapping the IAP again and downloading for free, but that's not ideal)
We're looking to test a solution to such edge cases.
However test accounts usually do not require valid CC info. Thus..
Question: How do I test such cases?
I have been using prepaid credit cards to test and make sure it goes through.
I've been implementing auto-renewing In App Purchases and, using the info found here, have had little trouble the purchasing, renewing, & restoring transaction flows.
The problem I am having is finding a way to test when a user renews (after, presumably, canceling some time in the past) from their account page in either iTunes or the App Store app (Detailed here). I'm assuming, since those exist outside of the sandbox and when you log into one of them using a sandbox account that account is invalidated as a test account, there is no way to actually test this use case so I'm just looking for more information on the expected behavior to try and account for it.
I know that keeping a copy of the receipt around to validate will give the latest receipt as part of the JSON payload, I'm more curious for information on how StoreKit will handle this renewal. Will paymentQueue: updatedTransaction: fire with a new SKPaymentTransaction as soon as I add a TransactionObserver or will it stay silent until calling restoreCompletedTransactions and then the new SKPaymentTransaction will be part of that?
Yes, you are correct; paymentQueue:updatedTransactions: will fire, just as if you were making the initial subscription purchase.
You can actually test this since renewals within the sandbox kick in at a much faster pace (up to six times a day) as explained here (scroll down to the bottom under "The Test Environment").
Also when you verify the transaction with Apple's verification service right after you made a test subscription purchase, look for the expires_date field in the response, it will tell you when the next renewal will be triggered.