I have a rails app with gem 'braintree'.
Documentation:
https://developers.braintreepayments.com/ios+ruby/reference/request/credit-card/create
https://developers.braintreepayments.com/ios+ruby/reference/response/customer
I would like to change the way I store customer ids in the vault. (say, from "BT_#{id}" to "SOME_OTHER_KEY_BT#{id}")
I would like to keep the existing cards each customer have in the vault.
Two approaches:
Updating existing customer ids in the vault. The problem is that I don't find a way to just update (doc) the customer, because I cannot specify the parameter customer_id. This parameter is used for reference, not as a value you specify to update.
Re-creating all customers in the vault. The problem with that is that I would need to re-add every customer card info, and I don't have all the information needed (such as the card numbers) to re-submit the info.
Any suggestions ?
I work at Braintree. If you have more questions, please get in touch with our support team.
The general suggestion in cases like this, is that you really shouldn't care what the Braintree customer ID is; you should store it along with your own customer ID in your database so you can map between the two. For all other purposes other than communicating with Braintree, you should use your own ID.
Related
I have a rails application in which stripe is implemented. However, I am getting an error in Stripe that says
for security reasons you cannot directly charge a source that is already attached to a customer.....
What I guessed from the error is that a card/source was already attached to a customer and some other customer is trying to pay with that card. Is it the case? Or is there something else?
And how to handle such scenarios on the developer end?
No, once a source is attached to customer A then you can't use it with customer B.
To avoid that error, make sure that each customer has their own Source and verify that the Source and Customers match when trying to create a charge.
In a Rails 4 application, I need to implement one-time payment system and add credits to user accounts.
Considering integrity and security, what is the best practice to store the user credit data?
Should I only implement an attribute to users' model or something else?
NOTE1: I use a custom payment system and none of the regular payment systems are of my use.
NOTE2: As it seems, using multiple databases in a rails application is not an standard.
To securely store users' credit data in your database, you will need to have PCI-DSS certification first and foremost. You can read more about it here.
To avoid that, best way would be to have a payment gateway store it for you, from where you can use the credentials for payments as required.
EDIT:
As per your comment for protecting important attributes NOT related to payment, you should try the Strongbox gem.
I think what you mean by "credit data" is not a credit card number, but an integer indicating how much credit a user has in your own "currency". As long as it's not absolutely confidential how much credit a user has, I don't think storing is a problem. It's rather about updating it.
Make sure it's stored in a central place, like the database. The session is not a good place for that.
Make sure to avoid race conditions when removing credit, read more about it here
I am using stripe for payment in my platform. Stripe provides me with IDs for the objects I can access in my account,
things like customer_id, which is like something cus_6DUY9LB2ih5Pdy
or credit card id like card_1613mtB177tQO9RpJRQEFLcV
If i had a delete link which references those ID like so
http://mywebapp.com/user/card_1614UyB177tQO9RpKy5Ysw10
for example, that link will delete the card from stripe and from my local DB
Is it safe for me to expose these IDs to the public?
can someone potential do malicious things with the card ID(like creating a charge?)
To get an answer marked on this, confirming what #koopajah said in the comment on the question years ago:
Those ids are specific to your account and only work with your secret key
So they are safe (nobody else can use them), but you may not want to expose these or build too much dependency around them. Instead, use your own data representation as a reference to them.
Currently I am creating a RESTful API for a mobile application. The RESTful API has a number of end points that allow users to exchange personal information between each other. I was testing how secure these endpoints were and quickly realized that if a third party managed to gain access to the API they could easily look up other user's information by guessing their user id or using an automated script to collect a wide range of personal information. This was due to the fact that I was using a primary key that was a simple auto-incremented integer which made it predictable and easy to determine other user's ids. I immediately began looking for something that didn't follow a distinct pattern. I came across UUIDs and decided to implement them with my existing rails app.
Was this a wise decision? I definitely see the upside to using UUIDs but upon further research I found that there were a number of negatives to this approach. Many sources claim that using UUIDs will cause performance issues with large tables. Are UUIDs right for my situation?
My second question is about implementing this in an existing Ruby on Rails application. I made the switch to UUIDs by following this article: http://rny.io/rails/postgresql/2013/07/27/use-uuids-in-rails-4-with-postgresql.html. I ran into an issue with enabling the uuid-ossp extension. I created a migration and put enable_extension 'uuid-ossp' inside the change function. I then changed the existing migrations to support UUIDs as their primary key and ran rake db:drop db:create db:migrate to recreate the database with the edited migrations. This failed with the error PG::UndefinedFunction: ERROR: function uuid_generate_v4() does not exist. I quickly realized that this was because I had created the migration that enabled the uuid-ossp extension after the migrations that I had edited to use UUIDs. When I changed the time stamp in the name of the migration to a date that preceded all migrations the db:migrate command completed with no errors. This felt very hack and defeated the purpose of having migrations. What is the correct way of adding this extension via a migration?
Edit in response to comments:
So a number of comments were made that suggested that I should just be properly authenticating users and checking their permissions before allowing them to view certain data. I have user authentication built into my application but will better explain my situation and why I needed something more than auto-incremented primary keys.
I have a number of users on this application and each user has the ability to create private and public contacts. Public contacts are viewable by everyone using the mobile application. Private contacts can only be viewed by the user who created them. However, a user can share their private contacts with other users by showing other users with the mobile application a QR code that has the contacts ID encoded into it. When the user decodes the contact ID a request is sent to the backend to notify the backend that the user is now an owner of that private contact. This allows the second user to now receive updates from that private contact. This is a large feature of my application. The aim here is to force people to have to exchange these contacts in person and to disallow others from seeing these contacts unless this process has happened.
Implementing this concept proved to be fairly tricky as all users could potentially share all private contacts with any other user on the system. I found this extremely hard to implement using permissions as which contacts a user can view is constantly changing.
Originally I implemented this with auto-incremented integers as my primary key for the contact IDs. It worked but forced me to create a very insecure API endpoint that essentially would take a user ID and a private contact ID as parameters and would add that user as an owner of that contact. Because auto-incremented IDs are so predictable a user with access to the API could essentially loop through a sequence of numbers calling the endpoint each time, pass the sequence number in as the contact ID and add themselves as owners to contacts that hadn't been shared with them. This would by pass the whole process of having to share the contact in person and in large defeats the purpose of having my mobile application.
I decided I needed something less predictable, completely random and unique to each private contact. I found UUIDs while doing research to solve this problem and changed the contact ID in my model to be of type UUID. Are UUIDs the best way to solve this? Should I use something else? Have I gone about solving this problem the wrong way?
Are UUIDs the best way to solve this?
You could use them as a solution. If you do, you should build a new contacts table and model instead of trying to migrate the old model. As well as being tricky to implement, any migration would immediately make existing contact/invite emails invalid (since they contain the old id). Briefly support both models, and retire the old auto-incrementing id model once you are happy that traffic using it is no longer important to your application.
There is still a flaw - your contact share links will now be long-lasting, and if anyone gets access to a contact's id for any reason, and know enough to construct the URL for gaining that user as a contact, then they gain the ability to share it to themselves and anyone else completely outside of the control of your application. This because you are relying on knowledge of the id as the only thing preventing access to the contact details.
Should I use something else?
In my opinion, yes. Use a separate nonce or one-off code model (with UUIDs, or an indexed column containing a long random string - you could use SecureRandom for this) that can grant rights to complete the sharing. When someone wants to share a contact, create the nonce object with details about what is being shared - e.g. the contact_id - and use it to generate email link pointing to a route that will find the nonce and allow access to the resource.
The model doesn't need to be called "Nonce" or contain that as a column, this is just a common name for the pattern. Instead you might call the new model "ContactShare" and the secret property "link_code".
This will allow you to resolve access to contacts using your app's permissions model as normal, and block the possible misuse of sharing links. When the controller with the nonce id or code is invoked, create permissions at that point in order to grant access to the contacts. Then expire or delete the nonce, so it cannot be re-used. I prefer expiry, so you can track usage - this can be as simple as a used boolean column that you update once the sharing request has succeeded.
Note I am not referring to Rack::Auth::Digest nonce routine, which is specific to server authentication. I did not find a RoR pre-built nonce model, but it is possible it goes under a different name.
First, notice I have read many post regarding this topic, but the info provided is not enough for me or is not accurate.
I´m developing a website with AngularJS and Ruby on Rails that offers different services. Users can subscribe to these services (one or many) and they get a Paypal Recurring Payment (through a profile) to pay these services (using merchant API). For a fixed amount the service is working ok for me.
The problem is, the amount can be different from one period to another, depending on the number of services the user is subscribed.
I have read Paypal docs, but It´s still not clear to me what is the right approach.
My approaches are:
Once a user subscribes a new service, I can remove the existing recurring payment profile (with fixed amount) and create a new one. This would be ok, but I have read I can´t delete a profile automatically from my application. I can only create. In order to delete an existing profile, I have to do it manually, by login in my business paypal account and delete it. If true, then this is not a solution for me, because I can´t do all flow automatically. However, this is quite strange for me. Is this true? If not, could you please let me know how to do it?
Although, I have not read deep on it, I read on a post I can use Reference transactions to implement this. Is this right?
UPDATE
https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECReferenceTxns/#recurringreftxns
As far as I understood, Reference transactions let me vary the amount to get from the buyer when I run it, but the problem is that this operation does not executes recurring (managed by Paypal). I should keep the logic in order to execute it from my application. Right?
Any other approach or clarification is welcome.
UPDATE
My first approach is to create just one variable recurring payment with the amount of all services subscribed. But, maybe the solution is to create a recurring payment profile per each service?
1) This is true if you're using Standard Subscription buttons, but if you're working with the Recurring Payments API you can cancel the profile using ManageRecurringPaymentsProfileStatus.
2) Yes, with reference transactions you can charge any amount you need to at any time, but it would be left up to you to build your own recurring payments system, basically, utilizing reference transactions. You could have a script run each day that goes through all your accounts and processes due payments accordingly.
Another option would be to have your users create a Preapproval profile and then use the Pay API to process payments using the preapproval keys. This is very similar to reference transactions.