I'm currently working on an iOS app where I would like to control the user experience of the entire checkout process when the user is paying directly by credit card. The PayPal iOS SDK doesn't quite fit my use case as it has a baked in ViewController that must be displayed to complete the payment.
The PayPal REST API's appear to allow me to charge a user's card directly but would require my secret key in the process implying it should only be used for some server side flow.
The PayPalPaymentViewController does have an option to take credit card payments directly from the user so I wonder if these services being used to accomplish this are publicly available?
First, I'd be curious as to why the provided view controller is inadequate. The goal is to provide a minimal interface in which to accept credit cards.
But, yes, these services are publicly available. A limited set of functionality (e.g. sale transaction) is possible by omitting the OAuth2 secret.
However, you will still want to verify the transaction on your own server in order to avoid being spoofed by a malicious user.
Don't try to replace the paypal ViewController with anything else, you might run into lots of legal trouble. For example, here in germany, the size and text of the "purchase" button is regulated by law. Paypal's Lawyers have checked the german version of the ViewController for correctness. If anyone, in germany, uses your app, and makes purchases with a different UI, chances are very high that a) the transaction is void and b) german authorities will prosecute you for fraud. Don't risk that.
Related
I recently received an email from the Google Cloud Platform Team notifying me of a policy violation stating that we had not completed the OAuth developer verification process and we're limited to 100 new user grants of which we're already at 60% towards.
The thing is, if I view this Oauth consent screen in the Google Cloud Platform, at the top of the page, it states:
Your consent screen is being verified. This may take up to several days. Your last approved consent screen is still in use.
This page was last saved and 'submitted for verification' some months ago now.
The page itself is constantly glitchy and poor anyway I've noticed at various points in the past.
The information this page contains is correct and I am unable to re-submit for verification unless I make changes.
Nonetheless, I'll make a change, resubmit, then edit removing that change and resubmit again but it's proving to be a bit of a hassle when either their system doesn't work or we're waiting on them to approve/reject the Oauth verification.
Am I supposed to be doing something else or is there a workaround at all?
Make sure that you've taken a look at the App Verification help page:
https://support.google.com/cloud/answer/7454865?hl=en
and the much more detailed verification FAQ:
https://support.google.com/cloud/answer/9110914
From the sounds of your post, it seems like you probably just need to get your app's branding verified because you are accessing sensitive scopes. That should be a pretty straightforward process if you have everything ready for review. Make sure you haven't gotten any messages from the review team with open items you need to accomplish. If not, you can make a trivial change and resubmit.
If you are trying to access a restricted scope like Gmail APIs, the process will be much more involved. Make sure you have all your requirements taken care of as outlined in the FAQ. And be sure you look closely at what scopes your code is actually requesting. If you are asking for sensitive or restricted scopes in your app but don't have those fully registered and approved in the developer console, your users will get warnings and you'll have restricted tokens revoked.
I have a client who is dead-set on using PayPal for Credit Card processing. The application must be able to charge cards without the user entering the information every time. Digging around, I've found the Credit Card Vault feature, which would at least let me store credit card information for future use. Unfortunately, as far as I can tell, there's no JS based tokenization procedure in the RoR Paypal SDK gem -- in order to store data in the vault, the information first has to hit my server. Which means I have to provide PCI compliance.
Is there any way to tokenize a credit card for later use in Paypal that will let the token be valid indefinitely?
In the REST API they call it the vault and they have documentation specific to it.
In the Classic API it's called a reference transaction, in which case you would use Payments Pro (DoDirectPayment or PayFlow) to process an original authorization or sale transaction, and then pass that transaction ID into future calls to process payments with the card data PayPal has saved on their server.
If using DoDirectPayment you would use DoReferenceTransaction. If using PayFlow you would just change some of the parameters in the typical request to make it a reference transaction. The doc links above cover all of that.
As long as you aren't saving any card data on your server then the only thing you'll need to be compliant is an SSL certificate on your site, but that's becoming a recommended practice regardless of whether or not you're processing payments.
If you want to completely avoid hitting your server then you'll have to go with Payments Advanced, which embeds a PayPal hosted iframe into your site. I don't think it supports reference transactions, though, and it's a lot more limited than REST or Payments Pro.
I'm a Freelance developer creating a site for a start-up company.
Getting PCI compliant at this time is going to be tough, since the site is still in major development and the funds are quite short.
The situation is this: They want to accept payments on demand in a fast and easy way. This is going to involve punching an id followed by a PIN into a virtual pinpad. This should process the transaction, charge the card, and be done. Because we are not currently PCI compliant, I would like the security to be as follows:
User, in Account Management, can click a link to redirect to the third-party payment processor (We are currently using Authorize.Net). On this page, the user enters their card information followed by email/some form of ID. Their card is saved through this third-party, and the third-party sends us their ID for the user as long as the user email (Or whichever identification used on our end). Now, when the user wants to create a transaction, we send the User ID, our API Key, and the transaction Key used by the third-party as well as the amount to charge. They charge the account and all is good.
Anybody have experience in this? Is this possible? Other solutions are welcome. Again, the company is slightly low on funds, and the transactions are usually going to be ~$10. They are currently working through 100% cash right now and averaging about 30 transactions a day, which is expected to increase drastically over the summer.
Unfortunately, with the new DSS 3.1, you may still need to perform a SAQ A-EP. Part of the requirements for the SAQ A-EP are:
Your e-commerce website does not receive cardholder data but controls how consumers, or their
cardholder data, are redirected to a PCI DSS validated third-party payment processor
Even though your site never takes or processes credit card data, since your site does perform a redirect, that redirect could be changed to point to a malicious site.
Further information can be found in the SAQ A-EP.
Let's say I am making a sign up form in which I asked user's twitter ID. How do I verify if the ID entered by user belongs to him/her? In case of verifying email we simply send a verification link which user has to click so how do I verify twitter ID? I have never used twitter before.
The only reliable and practical way to verify that twitter account X belongs to user Y this to do full on “3 legged” OAuth authentication. That being said, you may want to consider if you might be OK with just taking the user at their word on it.
Getting OAuth to work and securely storing the resulting tokens is much easier nowadays than it once was, but is still non-trivial.
Reasons to verify the twitter account, in increasing reasonableness:
You will be making enough server side requests, on behalf of multiple users, that you run up against Twitter’s API Rate Limiting. (Having multiple auth-tokens will allow for a higher API rate)
You need to automagically send tweets and/or follow accounts on the user’s behalf
N.B. do this as opt-in and be ultra clear about when/why you will be doing this, or you will face the justified fury of scorned users
Don’t verify the account if you’re looking to do these things:
You need to send tweets and/or follow accounts on the user’s behalf, and the user will be able to perform a browser based confirmation workflow for each of those actions; use Twitter’s Web Intents for this.
If you just want to pull in real time data for user’s avatar, bio, or recent Tweets Twitter supplies some prefab widgets for you.
All of the authenticated Twitter API Calls can be done client side with JavaScript. Twitter has a js framework, which does not require you to handle and store tokens on your server, to help you with that.
An alternate contact method for password resets, notifications, etc.
Private communication between users on twitter requires mutual following, many users probably never check their Direct Messages (or even know what a DM is), and any messages would be limited to 140 characters. Just use email for all that kind of nonsense.
If you’re just gathering this info to display it on a user’s profile page, in an “other places on the web” kind of way, integrating and maintaining all the server side OAuth pieces is likely too much bother. Just make sure you have a reasonable and clear TOS and an obvious way for 3rd parties to report any of your users who may be claiming a twitter account that is not their own.
If you’re still interested in OAuth, Twitter's Dev page has plenty of resources, including a nice overview of a generic “Sign In with Twitter” “3 legged” OAuth work flow.
I have an app that needs to use with a pay what you want model. I'm struggling to find a billing provider that offers this service outside of donate buttons.
The app is for a for-profit company, so I'm not sure if there is any gray area using Paypal, Amazon or Google for this. Outside of Paypal's 'donate' button, the process of allowing users to enter in a value they'd like to pay seems clunky at best.
I was wondering if there were any less known billing providers out there that offer a simple a nice pay-what-you-want or pay-as-you-will option. Merchant accounts and gateways arn't an issue.
Thanks
The possible isssues are You need to find international payment provider, User needs credit card.In case You use local payment system like netbanking you can target bigger circle.
For International payment Options are
http://www.wilsonweb.com/wct4/international.cfm
http://hubpages.com/hub/The-Top-International-Payment-Methods
Why not just implement it yourself, just like any other shopping cart app? The difference being that instead of the "cart" calculating the total for the user to pay, the user himself fills up the amount in a form. After that, just redirect him to the credit card processor with whatever amount he filled up!