I am integrating iPhone app with PayPal. I am transferring money from one account to other.
For now i am testing it in sandbox mode. When i transfer from account1 to account2 and even i don't have sufficient money in account1. I thought it would give me error something like "No sufficient balance", But it doesn't . It completes transection.
what would happen in this type of scenarios when my app will go live?
I have also face the same problem a month ago.You are right it completes the transaction without any error.But one thing you have to notice that
account amount in which you are transferring the money.You have no
change/effect on that.
When your app go online ,it will show the error or notification
That was done in my case.Just i put my app online.
Related
See here: https://www.paypal.com/ca/cgi-bin/webscr?cmd=p/acc/ipn-subscriptions-outside
There are 6 different notifications and I've never fully understood when I should use each one.
For example, when there is a sign up notification, does that mean I have the money?
Also, which notification do I remove their account on? If they pay for a month, then cancel their membership halfway through, but I still keep the money, what notification will be sent on day 30?
Basically, I need to know when to create their account and when to delete their account. There must be an easy way to this mess.
Thanks so much.
A signup is not a payment. It's just a new profile that gets created. You'd get a separate IPN for any payment that actually occurs related to a signup (subscription profile), so if your profile is configured to charge the first payment right away you'll get 2 IPN's right away: subscr_signup, and subscr_payment.
If they cancel their account you would get the subscr_cancel notification right away when that happens so you can update your database accordingly.
Same thing for the end of term. That's when you'll get a subscr_eot notification, so you'd kill their account in your system when that happens, too, or display a way for them to renew or whatever you wanna do in those cases.
This question is not basic so that means i have read some paypal documentation about this.
I have attached an image. The problem is that i make a Paypal subscription and while its active and stating that the next payment should be done next day, it doesn't happen, what could be the problem? BTW I am using the sandbox
The sandbox tends to get delayed sometimes, and payments don't occur exactly when they should. The production server doesn't have this issue, usually, but it can happen.
From what I can see you've got it setup correctly so it's just a matter of their system kicking in and processing it accordingly. Not a lot you can do it about it other than wait.
You could post a ticket to www.paypal.com/mts, but by the time they respond the payment will probably go through.
You could also call their tech support line, which you can find by logging in to your PayPal account, click Contact Us, then by Phone, and it will give you separate numbers for general and technical support. You can let them know what's going on and they may be able to find what's causing the delay and get it fixed.
I'm writing an iPhone app. The question is regarding the new rules restricting purchases inside the app.
So: the user charges their account up with 'credits' on the associated website using real money via a payment provider. The user installs the app and logs in using the same account as is used on the website: they cannot use the app without first logging in [edit: although they can register an account without adding any credits.].
The purpose of the app is to build up a report about a property, which can then be emailed out, or exported to their account to appear on the website. The report can be built up without using any credits. However, to export the report to the website or email it out, these credits must be expended by contacting the server and debiting X amount from the user's credits.
Here's the question:
The user's account is debited whenever they do this export. Only if/when the user's account is out of credit does the app complain that credits are low (otherwise it doesn't mention them), and it tells the user to go to the website to top-up their account to proceed. Remember that they can't login without an account, which can only be created on the website, and the website explains this.
From the guidelines:
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy” button that goes
to a web site to purchase a digital book, will be rejected
So, my app does not provide a link to the website when explaining that their account is low on credits, it just says that this is what is needed to proceed. The export function, however, does require that the user has topped up their account, so in a sense this does fall foul of the next rule:
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
I'm somewhat worried that this credit currency will fall foul of these recently-tightened rules, does anyone want to please reassure me (or, break the bad news)?
P.s. Spotify requires that users pay a subscription (on their website) to use the iPhone app. The difference between them and the above is that their subscription is unlimited-use whereas the above has a per-use charge.
Thanks in advance,
Ian
When you submit your app, include a tester username / password to the App Store. Fuel this account with a few million credits so they don't see the reference to Credits Low. There are many apps that get rejected just for having a login - if you make the reviewer's job easier by having a user/pw they can use, it'll increase your chance of acception.
If you app does get rejected, it means you have to change your model anyway. Actually - you might just be able to add 'Buy Credits' as an in-app purchase to appease Apple. Just make sure the credits in-app cost the same or less than externally - as far as I can tell, Apple will let you keep external purchases around as long as they cost the same or more than in-app purchasing.
Additionally, make sure your "low credits" alert doesn't link to an external page to buy more credits-- this may be frowned upon.
I'm sorry to break it to you but it definitely is a grey area and could potentially get your App rejected because you are asking the user to go to an external source to purchase credits which means Apple is cut out from any potential revenue.
I've had first had experience with this sort of rejection, all that was the issue was the description pointed to a web page where you could buy the product but Apple still had a hissy fit about it and added 2 months to the approval time and it ended up with me removing the link.
You could warn the User that their credits are running low, however pointing to the page to purchase them could potentially be the tipping scale.
On the other hand, there are some apps which make it through but there is no certainty. You are at the mercy of the reviewer in the end... You could potentially ask Apple Developer Support for any further information after describing your scenario.
I am trying to test my in app purchases using a test account. The first time I try to purchase an in app auto renewable subscription, everything goes smooth, no errors and the transaction is complete as expected with the transaction state updated to "SKPaymentTransactionStatePurchased". But, when I test for the scenario of a user trying to purchase the subscription again, I keep getting the above error. Even though the store kit framework displays a dialog saying that the user is already subscribed, my observer sees the transaction as failed in the state(SKPaymentTransactionStateFailed).
The storekit documentation clearly says
"If the user attempts to purchase a nonconsumable product or a renewable subscription they have already purchased, your application receives a regular transaction for that item, not a restore transaction. However, the user is not charged again for that product. Your application should treat these transactions identically to those of the original transaction".
In my case here, I keep getting the transaction state as "failed" when I do the purchase again.
Any ideas? This is in the sandbox test environment.
This is the expected behavior. You still receive a transaction, it just marks it in a failed state because it does not represent a new, successful purchase. Repurchasing a subscription they already subscribe to (presumably to restore a purchase after a fresh install) is not a journey you should encourage your users to take, they should be directed towards the restore purchases function.
Arguably you might want to interrogate your failed purchases every time to see if this is what the user was trying to do, but then you'd have to do a fair amount of messing around to try and distinguish which ones were genuine failures and which one's were erroneous restores. but I'd say it's much easier to have a big 'restore' button and direct people towards that.
If you log out from the app store application, it seems to be working when you purchase again. But problem continues if your user try to purchase the same product twice.
I was getting this when the Sandbox servers were down and/or broken. Check on Apple's developer forum to see if anyone else is getting the same thing.
[Developer Login Required]
http://devforums.apple.com/community/ios/integration/storekit
I just wanted to ask among the gurus here if anyone has ever attempted to test a complete transaction from start to end on an ecommerce site using paypal or any other epayment gateway.
Please guys, I would appreciate any thoughts and comments. As it is a live site, I cant use the sandbox as that will negatively impact sales. However my firm is a startup and so can't afford the complete transaction and refund process that was suggested [here]:Accepting dummy credit cards on a live site with ActiveMerchant & PayPal.
Please help!
Previously I tested by buying low cost items from myself - that way you're only paying commission and you're getting most of the moneyback.
Admittedly you need 2 Paypal accounts, but that shouldn't be a problem, and you should only have to 'kick the tyres' in the live environment because all your testing will have been done in the dev environment.
We had a similar problem during startup and still use this process in the live site. We have specific "test" products that we purchase using a live credit card, then monitor the transactions: purchase, decline purchase, subscription (recurring billing), cancel, refund, etc.
Our test product is priced very low (5 cents). For subscriptions, the billing interval is 1 day, for a maximum of 3 intervals (with a free trial period of 1 day). This allows me to run a full test/validation, including recurring billing, in the live environment in less than a week.
We refund all charges following the test, which puts the money back on the credit card (or back in the PayPal account). Because of the refunding, our sales impact is zero (offsetting sale and refund). It does cost us a small non-refundable PayPal fee for each transaction, but that amounts to $1 or less.
These "test" products are not exposed to normal users. Also, we manually verify any "test" sales to make sure they are part of our internal testing.
"Sandbox" testing is the way to go during development, but a periodic test in the live environment is necessary to be verify that nothing is amiss.
Why not use a real credit card, then give yourself a refund? The commision fee is returned in that case.
All the time that I want to test our live sites we use a real credit card.
Thanks
I don't understand why you can't use the sandbox..?? How would using it negatively impact your sales? It's all fake.
Just setup your own sandbox.yourdomain.com version of your site and use that as your test server. Configure it to use PayPal's sandbox with sandbox API credentials, etc. This will allow you to go all the way through an order process and test everything from the UI stuff to payment processing, API requests/response processing, IPN, etc.
When everything is working you sync it up with your live server, which is hitting the live PayPal server, of course.
Again, I don't see how that would impact you in any way other than being a successful testing solution..??