I am developing a website and it accepts payments for membership, paid using Google Wallet.
The DEV environment works. The call back function is intercepted, authorised, and the membership is automatically extended as expected.
The remotely hosted environment which should go live soon doesn't want to know.
When the user clicks on buy, an error message immediately pops up. It is ok for the user, but it doesn't say much else, making it useless for the developer. Maybe it's just me not finding the error code, or something similarly useful?
Anyway, the originated JWT String is valid ( the decoder here http://openidtest.uninett.no/jwt decodes it correctly, and the data in it is right ).
Any suggestions on how to fix?
I don't know if this is necessary at this stage or not, and possibly the cause, but the bank account hasn't been verified yet. ( For the developing I used the standard provided US sandbox account, I really hope that Google Wallet accepts UK bank accounts too, can anybody out there confirm? )
I found the cause of the problem, as mentioned above. I wasn't able to pick my own post as an answer before now. Best is to follow the steps above in case you do have problems caused by a missing one, different from mine. A big thank you to EdSF for his help! :)
Related
I am having a developer build me a website that he has been working on for about a month now. He's doing great, and it looks fantastic. Maybe I'm being paranoid, or maybe I'm not, but this is my first venture into an online business. He needed my stripe api key and secret key. Was it safe to give him the secret key for the coding end? He asked for both. Just wondering if I could be scammed somewhere down the line and not know it from the freelancer. Or be scammed and it is too late.....Sorry I'm coding illiterate for the most part. If I have to take any steps to ensure safety of any funds or my website after he creates it; please let me know.
For Stripe, and many other API systems like it, there are two sets of keys. One is for testing/development, and does not do any actual live work. The other is the live set, and that will hit the live API and allow the person with the keys to act as your business.
In an ideal, secure organization you'd have the live and test sides completely separated. The developers would not have access to the live site, and thus the live keys at all. Not in the UI, not in the database, nothing. This limits the vulnerability to only those people who are assigned to keep the live site running.
Since you're working with a freelancer it's a bit murkier. I'm assuming you don't have an internal team to handle the maintenance on the site. If that's the case then even if you were to insert the live keys yourself during the launch, the freelancer would likely be the person you're contacting to address issues, at which time they'll have access to the keys anyways.
However, if the freelancer will not be the person maintaining or supporting the site, then the best course of action is for them to provide you with a spot on the back-end of the site where you can enter the live keys yourself before making the site active to the public. Again, this is only something that provides security if the freelancer will not have access to the website after it is launched.
If he is your developer then he would need both keys. Here is some more information about the keys and what they can do
https://stripe.com/docs/keys
My client want to use OpenAM OpenIDM and OpenDJ for the product development. Before that client want to know what will be the production sizing for this forgerock.
Our plan is to have the 1 million user and 100K concurrent users are there then how much size it will take to on production. I have gone through the documentation of forgerock but didn’t find much information from it.
Deepak,
I am from ForgeRock and we would be very happy to help. As everyone's situation is different, we would like to discuss your requirements before providing sizing details to make sure we are not over / underestimating. ie. We want to get it right. :-)
There are a couple of options for getting in touch with your nearest tech resources.
Ping your request to this email address info#forgerock.com. If you could include the detail you have in this question, as well as your country and city, it will help the right person pick up your question and get in touch.
Here is a URL to our offices. I suggest calling your closes office for assistance. https://www.forgerock.com/contact/
If you can tell me your country / city, I can put you in touch with your nearest engineer.
Matt.
I am in the middle of the review process for Instagrams new API permissions. We have followed all of their guidelines and fall into one of their valid use cases. Unfortunately we have been denied now 3 times with the only explanation that we don't fall under a valid use case. I would be ok with this response if our software wasn't exactly what they say is a valid use case. So far I am unable to find anyway to contact them or talk about this issue. It would be a lot more helpful if we didn't get a blanket response when getting denied. Anyone else having these issues or have been able to contact their review team?
Perhaps this helps. I have tried two times but our app was declined. I will write the submission text one more time. I also want to go more into detail as the new FAQ says that Instagram expects a very detailed submision.
Cheers,
Christian
FAQ
My submission was rejected but it was a valid use case. What should I do?
A common reason for rejecting a submission is that we do not have enough information to make an assessment of your app. This can happen if your submission was too short, if it missed important information, if you did not provide a good screencast, your website is not working, etc. Before you submit for review again, make sure to provide a long and clear explanation of what your app does and how you use every permission. Make sure also to provide a video screencast and to follow all our Platform Policies.
What should I write in the submission?
The submission should be long enough for us to understand exactly what your app does and why you need the permissions you are asking for. If your submission is too short or does not explain all parts of your integration, then we may not be able to understand and approve your app. For example, your submission should explain what does your app or company do, which of the approved use cases your integration falls into, who will be using your app, how do your user authenticate with your app, how you use the API to power your integration, how does your product use the data acquired from Instagram, etc.
What should I show in the video screencast?
The video screencast is a very important part of a submission and cannot be omitted. Please make sure that the video clearly shows how your application works, including any Instagram login experience and the usage of every permission you are requesting. Since your app may still be in sandbox mode, you can use data from sandbox users to showcase the integration.
My company is working with multiple clients, should I submit one app per project?
No, we do not approve apps that are created for one-off projects (e.g. a hashtag campaign, an event, a website). You should use a single client_id across all your integrations.
Can I revoke a submission if I made a mistake?
You can't cancel a submission that is in progress. You will need to wait until the submission has been reviewed before you can start a new one.
I also have just been denied in the same way. I gave them 20minutes of video and demonstrated everything my app does. I wrote about each action possible in the context of use case 2 and I clearly stated which calls I was making. Short of supplying the source I am not sure what else to tell them.
David of the foursquare-support-Team directed me here to leave my question for answering here...
We are currently thinking about publishing our own venues on foursquare - about 1000 of them and more to come. We would love to offer a mayor special like "50% off the bill".
Getting the information, that the mayor just checked in: No problem here - already tried to implement that and it works.
But as we are going to give money away with our 50%-special, we absolutly need to be shure, that the person who checked in is certainly inside the venue.
The current fraud-detection does not work good enough for us - today I checked into one of our test-venues, when I was about 25km away. No good :(
Here is one solution I would love to see implemented at foursquare to solve our problem:
If "trusted checkins" are enabled, the venue can still be visited by searching for it or using its URL. When checking in this way, you are awarded the regualr points, but you cannot gain any mayorship or badge (like when checking in via the mobile foursquare website).
By using an API-call, a trusted-checkin-id is generated (for example venueid_token), that can be displayed to the user by a QR-Code, NFC-Tag, etc. When this special venue-id is opened, checkins are "trusted" and are rewarded with mayorships, etc.
Upon calling the same function again, a new trusted-checkin-id is generated (venueid_newtoken). Using this new id to checkin, you get all the benefits. Using one of the old special-checkin-id, will not give you those perks.
Of course, trusted-checkin-ids can only be generated by an account associated with the venues in question.
Using this - I think quite simple system - we could present our users QR-codes to checkin and be shure, they cannot cheat.
Additionally, the beauty of this soultion is, that it won't require any change in the mobile applications already deployed by foursquare. Everything can be done directly on the foursquare-servers.
I would love to hear from you girls and guys at foursquare-engeneering-hq.
Cheers,
Martin
Users are able to check in to venues anywhere, but if they're physically far away the check-in won't count towards specials unlocks or the mayorship. So while your check-in "succeeded," it didn't actually contribute towards you unlocking the special in any way.
These check-ins also don't count towards the merchant statistics, so you can look at the merchant dashboard for the venue and confirm that the "far away" check-in was not counted.
Actually, this is how Foursquare works. They allow to checkin from far away. There's currently no know way (at least for me) to avoid it. Could you please explain in more detail, what are these 1000 venues you're going to add and why do you need this 50% major-bonus for all of them?
The only way I could think off to do what you want is to create a custom application that would use FS api to post checkins, etc, but will have additional check based on location and some custom equivalent of mayorship. Basically that's what we've done to avoid fake checkins - additional location check inside of our app.
Currently, I'm in the process of hiring a web developer who will be working on a site that processes credit cards. While he won't have the credentials to log into the payment gateway's UI he will have access to the API login and transaction key since it's embedded in the application's code.
I'd like to be aware of all the "what if" scenarios pertaining to the type of damage one could do with that information. Obviously, he can process credit cards but the money goes into the site owner's bank account so I'm not sure how much damage that could cause. Can anyone think of any other possible scenarios?
UPDATE: The payment gateway being used is Authorize.net.
Do they really need access to your production sites?
Don't store the key in your code, store it in your production database, or on a file on the production server.
Some good answers here, I'll just add that you'd probably have some trouble with PCI.
PCI-DSS specifically dictates separation of duties, isolation of production environments from dev/test, protection of encryption keys from anyone who does not require it, and more.
As #Matthew Watson said, rethink this, and dont grant production access to developers.
As an aside, if he can access the API directly, how do you ensure that "the money goes into the site owner's bank account"? Not to mention access to all that credit card data...
If the developer gets access to the raw credit card numbers that can become a bigger problem as your site can be associated with fraudulent activity, assuming the developer is a bad apple. (They could redirect account numbers, CCV, expiration date to another site, though this should be spottable through network tools and a comprehensive code review.)
Does the API perform the "$1.00" charge (or "$X.XX") to verify that a credit card can be charged a certain amount (and thus returning the result to the caller, such as "yes" or "no")? If so, it could be used to automate the validation of credit card account numbers traded on the Internet and abuse of such a system could lead back to you.
With any gateway I have worked with, the payment processor ties the API key to the specific IP or IP range of the site of the merchant. With that said, unless the malicious(?) code in question is executed on the same server as the merchant - there shouldn't be any security concerns in that regard.
If this is not the case for your merchant site - contact them and ask if this is feasible.
Does the payment gateway allow for reversal of charges? If so there is the possibility of a number of scams being run.
Does the site process refunds? Will it ever in the future?
If we're talking about nefarious uses, then the site owner might be investigated if lots of unauthorized purchases are made. How would that affect you if the owner is investigated?
From your description it seems that this developer will have access to the customer cards detail in which case the customers privacy may be compromised. You might consider wording the contract appropriately to make sure that this angle is covered.
However the main point is that if you're working on a sensitive project/information it's better for you to find people you could trust. Hiring a software house to do the job may save you some sleep later on.
First and foremost, it is best that you never store this type of information in plain text. Usually people take this as second-hand knowledge for credit card numbers (Sadly, only because of legal reasons), but any sort of private data that you don't want others with database/source-code access viewing should be encrypted. You should store the account information somewhere in a well encrypted format, and you should provide a test account for your developers to use on their development workstations. This way, only people with server access are able to see even the encrypted information.
This way, you can have a database on the developer's workstation with the test account's API information stored (hopefully encrypted) in it's local database, but when the code is mirrored onto the production server it will still use the live, real gateway information stored on the production server's database without extra code/configuration.
With this said, I don't think that a programmer with API authentication details can do too much. Either way, it's not worth the risk - in my opinion.
Hope this help.
PS: If something bad does end up happening, you can always generate a new key in the web interface on authorize.net after you've taken the precautions to make sure it wont happen again.
In the specific case of Authorize.Net they would not be able to do credits towards their own credit cards since Authorize.Net only allows this to be done on transactions performed through them within the last six months. The only exception being allowed if you are granted an exception for unlinked refunds. If you have signed the proper paperwork for this and someone has your API login and transaction key then can then process credits towards their own credit cards. The only way for you to catch this would be to monitor your statements carefully.
To help mitigate this you should change your transaction key immediately upon completion of the work they perform for you. That would render the key they have useless after 24 hours.