I am trying to create a functionality using the Stripe API (not Stripe Connect) to let users add customers. If I understand this correctly, all customers will be added to my Stripe account. Is there a way I can distinguish which user added which customer, so that I can list all customers under one specific user?
I know Stripe Connect solves this problem, but it's not appropriate for my use case.
Thanks in advance.
About the only way you'll be able to do this - beyond tracking it in your own application's database, which you should definitely do - is to add Metadata to the Customers.
That said, you may want to reach out to Support and have them confirm that your use case makes sense; they may also have an alternative suggestion for you.
As #floatingLomas said, you can use the metadata field to store user info when creating a new customer (https://stripe.com/docs/api/customers/create), but as far as I know there's no specific API call to retrieve customers by metadata.
I mean, if your concern is to know who created a specific customer, it will be enough to retrieve that specific customer and look at its metadata field, but if you're looking for a solution which allow you to find all the customers added by a specific user, then I would suggest to create in your app a database table which keep track of that and do your searches through that.
Related
While going through the documentation, I can not figure out which is the behaviour in case multiple Products include the same API, and none of them requires a Subscription Key. Still, those can have different Policies, changing completely the context of the request.
So, imagine one open Product has JWT validation and another one does not. Which Product would serve the request that does not include any Subscription Key? Would it try with both Products in random order until one has a successful response?
Thanks a lot in advance! :)
I raised the concern in the official docs feedback process, and the answer is:
An API can only be associated with one open product.
I'm looking into building an exercise logger on a pre-existing Shopify website. Ideally, I would like to link the user's customer profile with the exercise data being collected. Does Shopify allow you to do this and store the data on their servers somehow? Or would I have to store the data somewhere else like MongoDB? And would it even be possible to link the shopper account with an exercise logger?
A customer logged into a Shopify store has an ID. You can use that to store exercise data on your own server. Using the Shopify Admin API you can setup connections between the store and your database. Therefore you can indeed have code that would run, and allow you to Create, Read, Update or Delete any information you wanted, on a store.
Note however that due to a current weakness in Shopify App Proxy, it is possible (but unlikely) that a malicious actor could try impersonating a customer by trying random IDs till they got one that worked.
I am working on a stripe backend in node and a react frontend, the idea being to create a platform for buyers and sellers. I have created the seller's side where users create connect accounts and add a bank to that account.
Now I want to set up the buyer's side. I want to be able to have a customer store their credit/debit card information to use to pay in the future. Below are my questions, they're a bit broad but I just want some basic guidance, not looking for code answers:
Should I aim to have users enter information and then have stripe create a customer object with all their information as a way of storing credit card info?
Can I use the react-stripe-elementslibrary to facilitate this process as it seems to be made to be secure? I've been looking at the examples but they seem to revolve around paying directly by inputting information to pay right away. Unless I am misunderstanding?
Should I aim to have users enter information and then have stripe
create a customer object with all their information as a way of
storing credit card info?
Yes, the main approach is to collect the card details which will produce a PaymentMethod object that you can then save to a Customer. The easiest way to do this is by using the SetupIntents API as described here:
https://stripe.com/docs/payments/save-and-reuse
If you follow that guide a PaymentMethod will be created automatically when you confirm the SetupIntent, and since you provide a Customer when creating the SetupIntent, Stripe will automatically save the PaymentMethod to the Customer.
Can I use the react-stripe-elementslibrary to facilitate this process
as it seems to be made to be secure? I've been looking at the examples
but they seem to revolve around paying directly by inputting
information to pay right away. Unless I am misunderstanding?
You should use the new React library from Stripe instead (assuming you're on React v16.8 and above):
https://github.com/stripe/react-stripe-js
The library is a simple wrapper around Stripe Elements which exposes an input field for your users to enter in their credit card details. When you use that pre-built input field from Stripe, they will automatically create PCI compliant forms for you: https://stripe.com/docs/security/guide. Otherwise, you would need to prove your business's PCI compliance annually which is a lot of work.
The client-side steps in the Save and Reuse guide all have a "React" tab that you can click on to show the React version (that uses the new react-stripe-js library):
https://stripe.com/docs/payments/save-and-reuse#web-collect-card-details
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 am trying to figure out the best possible way to manage a system where we will be sending out different documents via the api through one account. These documents will need to be handled by different departments. Is there a way in the api to share the envelope with a particular group/user? My other idea was to create multiple department API users and depending on which document I am sending will use that departments API user and associate that API user with the department user. It seems like a more complex solution but I know it would work.
Thanks,
Dan
I'm not sure why your question was downvoted without a reason, so I'll throw out my 2cents.
Question 1: Is there a way in the api to share the envelope with a particular group/user?
You can share all of a user's envelopes with group/user, but not specific envelopes. I do not suggest building a workflow around this.
Idea 2: Create multiple department API users and depending on which document I am sending will use that departments API user and associate that API user with the department user.
This is the best solution for scalability and customizibility, remember that an API user does not need to be an admin to create an envelope. In this case, it would be better if that user was not an admin, so they are limited to access only the envelopes that you'd want them to access.
I'm not sure what language your integration is in, but you should be able to store all of the credentials in an array/hash and just call the specific entry for username/password per workflow.
You didn't post what requirements you need for these workflows, so this is a very high level generic question and answer. You may want to go back to the drawing table and figure out your hard requirements. The solution above may not fit all of your requirements, especially if your security team has specific requirements that they need to have followed.
example requirements
Envelopes need to be created through the API
All envelopes must reside on the same account
Envelopes can't be seen by other departments
Envelopes need to be modified by department DepartmentName after Envelope Creation
The API needs access to view the status of these documents