We're a subscription-based business migrating from Braintree to another payment provider. We're hitting a wall with migrating our Apple Pay customers from one to the other.
The destination payment provider is requesting the Apple Pay PAN details. Braintree do not export this, but it would seem to be a requirement of any destination processor. As I understand it the PAN is the encoded individual card number for each transaction/customer - without the certificates (which we do have of course) the PAN is useless except to the original processor, but required by the destination processor so they're able to produce new ones for their platform.
tl;dr we need to obtain the Apple Pay PAN references for our Apple Pay customers. Neither Braintree nor Apple are able to assist it seems (so far at least).
Does anyone have any experience with this process that they can share insight from?
Thanks.
Related
I'm making a utility application for a photographer. He is going to (obviously) be taking pictures, but wants to charge people at an event for a handful of digital images emailed or shared on social media. In this situation i would have to use Paypal or Square SDKs and not in app purchasing because he is going to compose the transaction and not the customer buying the pictures. Sort of like a mini POS system. He can't pay himself with another's credentials - so it would have to be a 3rd party solution. right? Is this against Apple's guidelines?
Am I over thinking this?
If the intent is to support in-person / face to face (swipe) credit card or keyed in credit card payments, check out the PayPal Here SDKs for iOS and Android which are now available on the PayPal Developer site:
https://developer.paypal.com/webapps/developer/docs/integration/mobile/pph-sdk-overview/
There is also a version for Windows 8.1+ in Beta, available upon request. You can email DL-PayPal-Here-SDK#ebay.com for help with any of these.
I have a Windows Store app for a newspaper in the Windows Store. Each issue (one per work day) can be bought using in-app purchases. In Windows Store, it looks like i can define only 100 in app purchases. In my case, that is about 4 months of daily issues.
Is 100 really the limit? Has anyone found a way to add more?
I cannot find a way to add more in-app purchases to the app. The milit of 100 would be a really stupid constraint and I would need to remove to ability to buy old issues in order to add new issues.
Windows 8 doesn't support subscription-based purchases but it does support time-limited purchases.
One option is to let the user purchase "credits" that can be applied toward an issue. Similar to how Audible lets you purchase audiobooks with credits.
Here's the thing though. Newspapers make money off advertisements. The purchase price isn't for the content, it's for the materials that it costs to deliver the paper. A digital paper costs nothing to deliver so why are you charging for it?
The store does not support subscriptions. However you can just use a third party provider for this.
As mentioned in the 'Flexible business Model'
http://msdn.microsoft.com/en-us/windows/apps/hh852650.aspx
The Windows Store provides you with the freedom to choose the business
model that’s right for your apps. The Store provides full platform
support for free apps, trials (both time-based and feature-based), and
paid apps, as well as in-app purchases. You’re free to manage customer
transactions directly using your own or third-party services for
in-app purchases and subscriptions, or use the services provided by
the Windows Store. For apps that are supported by ads, you’re free to
choose the ad platform that best meets your goals.
Paypal is accessible via this api:
http://paypal.github.com/Windows8SDK/
or directly via a form post
How to Form POST to Paypal from WinJS iframe Windows 8 App?
We are about to develop new mobile application that requires the end user to fill his payment information, which will be redirected to a third party’s portal to pay for a certain services through the application ( using Web Services )
user send billing information using web services , Is this legal for apple ?
It's OK to integrate 3rd party credit card payment systems in your app (for example PayPal, Amazon payments, etc. or your own system) as long as you do not sell services, extensions, etc. to your app. As you say you're going to sell physical goods, it is OK for Apple. Amazon app does the same thing. Btw it is even explicitly prohibited to use in-app payments to sell physical goods.
EDIT: more answer to the detailed questions in the comment
IMHO (see disclaimer):
Shipping fees of physical goods and signup fees for your physical service are NOT services or extensions - in the sense that Apple uses it, it applies only to some additional features to your application, for example a new level in a game or a new map in a mapping app
to be legally store, transmit, process credit card information, you will have to be compliant to the Payment Card Industry Data Security Standard. Here Apple has nothing to do, but both Visa and Mastercard (and maybe also other card issuers) require that you implement these practices if you wish to process credit card data of their cards
this last requirement might be tricky so I really suggest you to look for some ready solution instead of implementing your own. See also the first answer to this question: Use In App Purchase For Real Goods
DISCLAIMER: I am not a legal authority or somebody from Apple so I can give you just hints but not a legal advice - will have to ask a lawyer for an "official" answer :)
I have developed one app in which i have used the Google Place API. This is what places doc says about limitation.
The Google Places API has the following query limits:
Users with an API key are allowed 1 000 requests per 24 hour period.
Users who have also verified their identity through the APIs console are allowed 100 000 requests per 24 hour period. A credit card is required for verification, by enabling billing in the console. Your card will not be charged for use of the Places API.
So my question is that if i enable billing for Place API then its free? Is it really true?
Yes, you will have what they are saying. I have done that, so I can confirm... If you put your credit card info, you are letting them know that you are a verified user, and that therefore you won't misuse their services.
And for the second question, we are talking about Google here. It is really true, you won't be charged, they can make money from other sources :)
EDIT:
Actually, if you need more than the "verified" option, it seems you can contact them as stated by Thor Mitchell (Product Manager #Google) in this topic at Quora: Pros and Cons of Places API
"The limits on use (after identity verification) is 100,000 requests
per day, and we're happy to talk to developers who need more about
their requirements."
As of today, the limit is 150,000 free requests per day, but the documentation is hard to make sense of in terms of how they bill overage.
Latest update March 2019:
"For an overview of pricing for the Google Maps Platform products, please see the Pricing Sheet.
To learn more about how Google Maps Platform APIs are billed, please see Understanding billing for Maps, Routes, and Places."
Before jumping in I'd like to know what all of my options are, and, if possible their pros and cons.
The two I know of are using ActiveMerchant, or the paypal_recurring gem, but will they satisfy these requirements?
Ability to accommodate monthly and annual billing
Ability to suspend, cancel accounts etc
Deal with out-of-date card details or failed payments
The to-do list for the paypal_recurring gem includes 'adding support for IPN' - how will not having this impact functionality?
I know there is the railskit SaaS but I'd rather code something myself as the railskit is still on 3.2.1.
I know there are services like cheddergedder/chargify etc, but do they tie you in? Are they US only? Are they worth considering - or are they usually just aimed at non-developers?
Thanks in advance.
I just finished going through this, so I'll try to shed some light on your options. I ended up using Paypal Express Checkout for all recurring purchases through Paypal. We had a custom-rolled recurring billing setup that charges a customer's credit card monthly through Authnet, but had to switch because we needed an international solution, and Paypal was one of the only ones that supported the currencies we needed, and wasn't entirely a nightmare to code.
You can use ActiveMerchant for recurring billing with this plugin, though keep in mind that it is not officially a part of ActiveMerchant, and therefore is subject to break if ActiveMerchant changes how it handles certain things. Because of that, I ended up using the paypal-recurring to handle communication through Paypal, and then rolled my own IPN parser, with help from Railscasts. Another link that helped me a lot was this, though all the :txn_type values ended up being different.
With regards to that last link, here are the 4 :txn_types that I specifically watch out for:
express_checkout - first postback.
recurring_payment_profile_created - sent on first postback when the user first subscribes.
recurring_payment_profile_cancel - sent if user cancels subscription from Paypal's site.
recurring_payment - Money has been transferred to your account. This is what I wait for before I renew their subscription on a monthly. This post also comes with payment_status, which needs to be completed.
The other stuff you mentioned, like handling failed payments and out-of-date cards, is handled through your Paypal account.
Just a word of warning - the only reason I ended up using Paypal is because it is universally recognized and trusted, and it accepted international currencies. There is an enormous amount of documentation on their site, and most of it is redundant, confusing, and entirely too long. My recommendation is to make sure you really want/need to deal with recurring payments, as they are difficult to implement correctly and can be more trouble than they're worth.
I'm currently looking at Ryan Bates example of Stripe. They are a California based company that uses/offers the features you have listed.
www.stripe.com
They only charge when you receive money. I think that they are 3% plus $0.30 per successful transaction. Much better than some other companies that have a monthly minimum. Right now you have to have a bank in the USA to use their services as a merchant. However, anyone can use your site with out of the country credit cards.
The SaaS Kit is now tested with Rails 3.2.2. :) It doesn't support IPN yet, but it's on to the todo list. With all the info here in one spot, I suppose I have no excuse not to get it done. :)