I am having some issues currently wrapping my head around the process of adding a customer to a plan.
A very broad idea of the payment type is to think Twitch Streaming. You can follow users for free but pay a small fee to "subscribe" to them.
Currently, when the user fills out the payment form, i create a source in the frontend through react-stripe-elements and then pass the source.id to my backend.
This is where things start to fall apart for me.
Should I create a different product per user so I can very easily view from the stripe dashboard which user/product is doing the best?
A way to go about this is when a user creates an account, my backend automatically creates a product for that specific user as well as a plan and then store the plan_id into the user model.
So when a user subscribes to another user, I can pull out the plan_id and create the subscription that way.
Currently, I create a source whenever a user submits the payment form.
let attach_source = async ( customer_id, source_id ) => {
await stripe.customers.createSource( customer_id, {
source: source_id
} )
}
Do I check if an error happened and see if the error is duplicate source? Or does Stripe take care of everything.
I am also curious how Stripe handles multiple subscriptions on the same customer from different credit cards. I don't see anywhere that states that a subscription takes from a specific source.
Thank you for taking your time to read this. Appreciate the help!
it looks like you are describing a billing user case from Stripe (https://stripe.com/docs/billing/subscriptions/creating)
You can probably get away without creating one plans per one customer. what you could do is to create a Plan with usage (https://stripe.com/docs/billing/subscriptions/quantities) so a min plan of 5 dollars subscription, when they want to contribute more, update the quantity of the plan
Currently stripe source has a fingerprint fields, where it will be unique for the same credit card number (https://stripe.com/docs/api/cards/object#card_object-fingerprint), you could compare fingerprint to determine if the card has been added. Stripe does not perform any duplication checking now
There is a default_source (https://stripe.com/docs/api/subscriptions/create#create_subscription-default_source) parameters where you can set different card for different subscriptions;
Related
for my subscription based product I want to have a possibility to subscribe and enter payment details at once with stripe and struggle with that with the api.
In https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements I see an option to create a subscription with payment_behavior='default incomplete' and then enter the details to confirm the payment intent. So far so good. However if I create the subscription like that even before the customer confirms payment details stripe already generates an invoice which is not really what I want before final confirmation by customer.
Options I see:
create setupintent, have this filled by customer via elements and then have the customer subscribe. Technically works nicely but for a sales and customer perspective is not good as it has two steps thus probably reduces conversion.
create the subscription in the background before final subscription confirmation by customer and use the clientsecret of it to pass back to browser and then have customer enter his payment data and submit that and finish the setup of subscription and payment info. Technically works - however I realize that when I create the subscription to get the clientsecret to pass to elements before the customer enters his payment data and confirms the subscription the subscription is not only created but an invoice too - which would be really, i.e. an invoice created before customers really confirms the contract
create setupintent and submit it via elements and in metadata of it add the info of product that customers wants so that when the paymentmethod gets created and I get webhook event I do the booking of the product given in metainfo. May however mean the customer gets to success page but the webhook has not notified yet and thus the customer is not really subscrubed at the point in time but gets a success message he is
same as 3 except do not pass info via metadata but via successUrl parameters which refers to and endpoint at my backend which upon being called after setupintent was setup will do the subscription and then redirect to my frontend which shows success page. That seems like a error prone workaround however.
Create a workflow which is a 2 step sign up and asks for paymentinfo, sets that up and then brings customer to a final confirmation page where the submit triggers subscription creation. Seems a bit complicated from a user flow, but so far probably the best option?
Any better options?
Cheers
Tom
ps: Interestingly enough on discord stripe support told me #2 is the way to go - find it hard to believe ...
As far as I know, there isn't a workaround for this unfortunately. It is just how Subscriptions API is designed by Stripe. You can learn more about that here where they talk about "how subscriptions work".
I am updating my billing page which used Stripe JS V2 tokens and the Charges API (Subscriptions). The new(er) Payment Element looks slick from a future proofing standpoint, but am I understanding it correctly that the Customer object must be created prior to populating the payment form?
I only create the Customer once the payment token is obtained and a user has a clear intent to purchase after evaluating during a trial period. Otherwise my Stripe Dashboard is overrun with "empty" trial users that never sign up (I only have around a 10% signup rate from account creation). I guess this is mostly just a personal peeve, but I also just don't like to share user data and figured this way I would only be sharing with a third party once they become actual customers of mine.
Since a Subscription cannot be created without providing a Customer as part of the required parameters, am I stuck using the Card Element and the older Charges API if I don't create a Customer for every user in my system?
You really should just create a Customer up front. It will be required if you want to use trials with Subscriptions and will be cleaner in the long run.
For a workaround, which I would not overall recommend, you could use a SetupIntent with Payment Element to collect the customer's payment method without actually creating a Customer object. Then you can later create the Customer object and attach the PaymentMethod that was previously collected and then create the Subscription.
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.
With Stripe, how to use the payment method created from setup intent for multiple customers?
According tp the Create Setup Intent API, it only let us define one customer ID.
param name: customer (optional)
description of this param:
attached to the Customer on successful setup. Payment methods attached
to other Customers cannot be used with this SetupIntent.ID of the Customer this SetupIntent belongs to, ifone exists. If present, the SetupIntent’s payment method will be
TLDR
I want to let the same user to reuse same payment method to subscribe items with different presentment currencies,
I assume I should solve this requirement by directly creating multiple customer objects for a single user, and using create Setup Intent API to attach his/her same payment method for multiple "customer objects".
But, I am not sure if this is possible, therefore I welcome any recommendation for alternative approaches, such as using attach payment method to customers API, or any workarounds.
PS: Detail info (for why I am interested to ask this question)
Business requirement:
My business requirement is that customers have to subscribe to international services that must be presented with different presentment currencies. To makes thing even harder, each customer has to use the same list of saved payment methods to subscribe to services with different presentment currencies in the future. In other words, users should not have to re-enter card info again if they subscribe to items in different presentment currencies.
Limitation of the Stripe API:
Why not just use single customer object for subscribing to services (aka "price" objects) with multiple presentment currency?
I tried and it results in an error. According to this Stripe documentation, it indeed says that each customer can only be used for transactions in single currency.
If the user in my app want to subscribe to another service with another
currency, I need to create new "Customer" object in Stripe.
Why not just use /v1/payment_methods/:pm_id/attach api to attch payment method to multiple customer object?
Because according to this Attact payment method to customer API doc, Stripe does not recommend, yet I do not fully understand the risk of not performing any necessary steps as it warns. Therefore, it is just my risk averse instinct to avoid this.
To attach a new PaymentMethod to a customer for future payments, we
recommend you use a SetupIntent or a PaymentIntent with
setup_future_usage. These approaches will perform any necessary steps
to ensure that the PaymentMethod can be used in a future payment.
This is not supported. A payment method can only be consumed once if not attached, and attaching to a customer counts as a consumption. A PM can only be attached to a single customer, so you'll need to collect the payment details for each.
Stripe recommends using that customer's currency for all presentment to optimize for their experience, though that may not be suitable for all use cases.
I've been looking through the docs, other tuts, but nothing is straight forward on this.
The docs shows:
saveStripeCustomerId($user, $customer->id);
There's not one line of code, or comment to explain where, or what code is in this function.
another person asked on here how do you store tokens. The answer was don't store tokens save customer IDs, or something like save customers. They neglected to say how or where to save them..
Can I ask the questions once and for all?
How do you re-use Stripe customers?
You don't need to get involved with subscriptions at all to create a customer. A Customer is required to create a subscription, but not the other way around.
This line of code below is an example of a function you would create and run to save the customerId to your database, it is not a stripe function. It would be up to you to populate that function and handle the database transaction.
// Save the customer ID in your database so you can use it later
saveStripeCustomerId($user, $customer->id);
This line of code more specifically is the creation of a customer. When executed it will return a customer object which you can use, and add/remove cards to/from, and charge those cards.
// Create a Customer
$customer = Stripe_Customer::create(array(
"card" => $token,
"description" => "payinguser#example.com")
);
By saving the customerId to your database you can retrieve and charge that customer at any time without storing a credit card or personal information.
I found the answer, but assume no responsibility for my lack of understanding, lol.
The docs say:
Once you've created a customer, you should store its id in your own database so you can refer to it later when communicating with stripe.
but guess where? Under subscription, something I assumed I would never need because I'm not doing anything with subscriptions. I would think this important detail would have been mentioned with customers...