I want to know if it is safe to expose the charge ID e.g. ch_abc123. I want to know this so I have a way to issue refunds to a customer securely.
I was thinking of asking the customer for their details e.g. email, date of purchase but then I thought that there would not be a way to ensure the identity of the person requesting a refund.
Ideally, I would show the customer the charge ID so they can provide it when asking for a refund.
The charge ID itself is a unique ID that you can't do anything interesting with on its own, except by using your Stripe secret key, which you should protect.
But precisely because it is a simple unique ID that is not considered sensitive on its own, you should not rely it on as a form of authentication — the customer might share it or have it stolen. Or they could lose it and still want to get a refund.
I would suggest instead that you store the charge ID on your backend server along with any other order metadata that you have, and provide the option to request a refund only after the customer has authenticated to your system.
Related
I have strange situation ... I want to convert my guest customers in my stripe account to the real customers ... Real customers have the customerID but the guest customer doesn’t have the customer ID ... Is there any way to convert them.
Guest customers are only available in Stripe Dashboard so there is not a way to manipulate them via the API and there is not an option to convert them to a customer object via the Dashboard.
The recommendation is to create real customers moving forward. Although there is not a way to associate previous payments to real customers, you’d be able to track payments that belong to the same customer and create recurring charges. To achieve this, you’d pass the customer object on the PaymentIntent creation or if you’re using Checkout, you’d pass it when creating the Checkout Session.
I’m looking at building a solution that allows for users to have an account with my website that is linked somehow to their corresponding stripe customer account. The way I am currently doing this is by using an external database server which holds customer account info such as email, password and stripe customer id. The stripe customer id is used to look up stored credit cards and billing info for the user. The problem I have with this current implementation is that the only reason why I am using an external database for this is to store a password securely (hashed of course) and this seems a little unnecessary.
Another thought I did have was to take advantage of the metadata property of the stripe customer object to store the hashed password. This way all customers live in stripe and that’s it. Is there any issues with doing it this way?
Sounds plausible. Did you try it out?
I'm setting up OneSignal on my website.
As far as I can see, there are 2 ways I can associate a push subscription with my user ID:
I can call OneSignal.getUserId(), which returns a UUID, and make an authenticated call to my web server to associate this UUID with my logged in user on my server
I can call setExternalUserId() to send the logged in user ID and associate it with the subscription on OneSignal servers
The first option is perfectly secure, as one could only hijack my client-side code to send an invalid subscription ID (or another valid subscription ID they have created), which is not a big deal.
The second option though, feels totally unsecure: anyone could hijack the client-side code to send any valid user ID and associate it with its subscription, and therefore receive notifications on behalf of another user.
Is there a way to securely use setExternalUserId() while preventing a user from associating their subscription with another user?
The only secure scenario I can think of is if my users had UUIDs as well, instead of sequential IDs, and these UUIDs were kept secret (i.e. never exposed publicly on the website).
Any other scenario I can think of sounds plain insecure.
Did I miss something?
I have a subscription service for which free trials are allowed before signing up for the full payed service. I want to ask the customer to provide credit card details before gaining access to the free trial, to prevent abuse of the trial.
I'm using Stripe to handle payments so that I don't have to deal with storage of any sensitive payment information. This free trial scenario would seem to be very common, so I assumed there would be some way to query a card to make sure that it hasn't been used to sign up already. Just some API call that would accept the card number etc. and return a boolean.
I haven't seen anything like in the API docs. I know that fingerprints of cards are accessible after creating a card source, so is it advisable to store them myself and query them? Or have I missed something in the docs?
Just to be clear... I'm not looking to search a card for a particular customer. I know I can iterate over the cards to do that, but I'd have to iterate over the cards of every customer to accomplish what I want, which is not feasible.
Here you probaly want to contact the support team and suggest this as a new feature.
A possibility is the fingerprint you mention, in my opinion this would be the way i would do it too.
One single card should never be associated with one customer in a platform.
No, there is no way to check whether a credit card is used for another customer or not. And there shouldn't be. Because a customer has right to use his/her single credit card to maintain more than accounts.
You can easily integrate trial feature of a Subscription in Stripe which is best way to implement Trial feature using Stripe. If any customer's payment failed after trial expired then you will be notified by Stripe.
And Stripe and any other payment gateway is not advise to store any card info due to security issue.
I think that the Dwolla API sends the wrong transaction ID in notifications. In a normal dwolla money transaction, two transaction IDs are created (this is weird to me, but that's how dwolla does it). Because these two are created at the same time, they are always (in my experience) consecutive numbers.
So e.g. if account X sends money to account Y, Y will see transaction id M, and X will see transaction id M+1.
But Dwolla's notification webhook will send Y details of the transaction with id M+1. While ID M+1 is still unique to this transaction, ID M+1 cannot be used by Y via the API - because M+1 is supposed to only be used by X.
Here is a specific example:
Via my webapp, I send money from my personal dwolla account to my organization's via the off-site gateway api.
My webapp is sent the transaction details in both callback and notification form. The transaction id generated by step 1 is 1431566. This is the transaction id sent to both callback and notification. My web app stores this Id for future use.
Via my webapp, I decide to refund my personal dwolla account from my organization's so:
My webapp tries to query dwolla about transaction 1431566, to get the SourceId, but this fails - dwolla reports "Transaction not found for account". My automatic refund cannot continue without an ugly kludge like subtracting one from the Id and trying again.
The manual workaround is to login to my organization's dwolla account via the web interface. Here I can look for the transaction based on datetime and I can see that the transaction ID is actually 1431565 (correctly reported in the web interface). If I go into my organization's database and replace 1431566 with 1431565, I can repeat step 4 and it works this time. After that I can initiate a send() and the refund goes through.
I reported the same problem here before dwolla moved support to stackoverflow: https://getsatisfaction.com/dwolla/topics/callback_and_webhook_notification_sent_wrong_transaction_id_off_by_one
I figure it will be fixed faster if other people have the same problem. Or maybe I'm missing something obvious and someone will point it out.
Thanks to Michael's help, we were able to get around this issue by using the receiver's OAuth token when getting the transaction details instead of the sender's OAuth token.
For example, say I send some money using the API and transactions 1202 for the money sender and 1201 for the money receiver get created. If you make the API call to get details for transaction 1202 but use the receiver's OAuth token, it will give you details for transaction 1201, including fee information.
I'm not sure if the situation is exactly the same since we are acting as the facilitator between two transactions, so no guarantees that this will work in your situation. But it's worth a try.
So, your application's key & secret can access the transaction ID posted to you by passing the transactionById() method your application's client_id and client_secret, as opposed to the oauth_token. Meaning, when you poll for the transaction, instead of querying this URL:
https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?oauth_token=x
Query this url, instead:
https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?client_id=x&client_secret=y
Makes sense?