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.
Related
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 am currently hitting a roadblock implementing Stripe Connect into our platform. We want to allow multiple connected accounts to use our platform to sell some sort of tickets. For this we wanted to use Standard accounts with Direct Charges (since we want to take a cut and also not have to deal with refunds/disputes etc.).
On our end the end-user has to either select or create a customer on our platform (created in our Stripe account) and then provide their payment method details through Stripe Elements. The documentation states that you need to create a PaymentIntent for the connected account, but this is not possible while also supplying the previously saved customer (because the customer only exists on our platform).
Now another documentation outlines that it is possible to share customers between connected accounts. The issue with this is that for this step you already seem to need a payment method attached to the customer:
If your platform uses the Payment Methods API, you must create a PaymentMethod from that customer.
The linked documentation outlines how to clone payment methods of customers between linked accounts, but this once again assumes that we already have a confirmed/attached payment method.
So my question is: How can we allow customers to be shared between all connected accounts without having to supply a payment method first? After the first payment (and if the customer chooses to do so) we want to save (and later clone if necessary) this payment method for future payments on all connected accounts.
For normal payments you can create a PaymentIntent with a customer but without a payment method and only supply the latter on the client (in our case stripe.js)
Since you're using Standard accounts, you have to use Direct Charges when accepting payments on behalf of that connected account. This means that the PaymentIntent has to live on the connected account, alongside the Customer and the PaymentMethod if any.
If you want to re-use the payment method details for other accounts in the future though, the PaymentMethod itself and its associated Customer has to live on the platform account.
Unfortunately, there's no way to "clone" a PaymentMethod from the connected account back to the platform today. This means that you have to change your integration logic slightly and approach the overall flow differently.
The idea is that you first need to collect payment method details in the platform. Since you're not taking an immediate payment during that step, you want to use the SetupIntent API. This is the flow documented here that will let you create the SetupIntent on the platform and collect card details securely client-side.
Once you have this information, you will now have a Customer cus_A in the platform, with the PaymentMethod pm_123 attached to it. That is the first step of the flow.
Now, you want to accept a payment on the connected account. So you first need to clone the PaymentMethod on that account as documented here. That will give you a brand new PaymentMethod pm_xyz that lives on that connected account. You can then use that PaymentMethod to confirm a new PaymentIntent on that connected account and passing payment_method: 'pm_xyz' to attempt to charge that saved card.
Note that it is possible this requires a "next action" such as doing 3D Secure as it's on a different account which could come with different restrictions.
In the future, if that customer comes back and wants to pay another connected account, you'd do a new clone of the PaymentMethod on that account and a new PaymentIntent for that cloned card and you can repeat it each time they pay a new business.
It can seem a bit convoluted at first, but once you grasp the flow of all the objects it does make sense overall!
I've been reading Stripe's api documentation (v3) and it's not apparent to me when to use Stripe's Invoice vs PaymentIntent objects. From reading the documentation, here's what I understand:
Stripe sees payment intents being the primary way of facilitating payments through their API going forward and Charges will be deprecated at some point.
Processing an Invoice creates a PaymentIntent under the hood and and initiates payment right away. What I don't understand is why is there no destination account field for the Invoice? If the Invoice is defaulted to be sent to the platform's Stripe account (this is an assumption I am making since there is no destination field), why there is an application_fee_amount field which is essentially the platform's "cut" of the transaction?
A PaymentIntent allow you to specify a destination account while taking an "application" or "platform" fee so you don't have to generate a transfer yourself.
A PaymentIntent and Invoice can be processed at time of creation or deferred until later in your payment lifecycle.
My use case requires me to conduct payments between two parties and take a "platform fee" for each transaction. I have successfully done this by creating a PaymentIntent and using the connected Customer account's credit card on file and populating the transfer_data field with the amount to send to the 2nd party involved in the transaction.
I started looking into Stripe's invoicing api since I am planning on building an invoicing solution for my platform and thought it'd be best to leverage what Stripe has to offer, but I'm failing to see a benefit for me to leverage it since I also need to keep track of transaction ids for the payment intents and taxes based on zip code (it looks like Stripe doesn't do this automatically so I might be out of luck here).
I couldn't find a way to get a transactionId for processing an Invoice but I see that the chargeId gets returned as part of the response when you confirm a PaymentIntent (https://stripe.com/docs/api/payment_intents/confirm).
So the questions I have are:
Why is there no destination account field for the Invoice? Does it automatically get send to the platform's Stripe account and require you to manually create a transfer?
Is there an easy way to get a transactionId from an Invoice?
Is there a way to get a transactionId when creating a PaymentIntent and setting the confirm=true so the PaymentIntent gets processed immediately?
For a platform that will have an invoicing flow and facilitate transactions on behalf of two parties, is it recommended to use payment intents, invoicing, or both?
What's the difference between a charge and transaction? When paying an Invoice, a charge id gets returned in the response but when paying a payment intent, a transaction id gets returned.
Thanks in advance!
You can think of invoices as subsets of payment intent, kind of the same way subscriptions are subsets of invoices.
What I don't understand is why is there no destination account field for the Invoice?
Actually there is one, but the field is transfer_data[destination]. Also, note that whenever an invoice is finalized, it will contain a payment intent, which is expandable, and with which you should be able to solve most of the issues you rose in your question.
To sum up:
Yes there is, as explained above.
Expand the invoice's payment intent object.
I'm not used to work with transactions, but I guess you could leverage their metadata to reference your invoice or vice verse to help you retrieve the need object in needed time.
As explained above, their is not dichotomy between those, if your invoicing your clients, the you should use stripe's invoicing system.
From what I see in the docs, transactions only concern purchase 'internal' to stripe, with issued cards. Charges are the attempts stripe will make to charge your bank account through the network, when a charge succeeds, the payment intent status is set to succeeded otherwise the payment intent might attempt more charges or stop trying at some point, and the payment intent will be set to canceled more about payment intent statuses here. In short payment intents are a subset of charges.
I hope this helped and didn't come too late, the answer might still be improve in the future, if others edit it or as I will learn more about stripe's issuing product.
I'm integrating Stripe Subscriptions in our workflow, but when creating a subscription with a Customer created with a paymentMethod instead of source I receive the error This customer has no attached payment source.
If I call in the browser createToken() and attach it to the customer in the source field it works.
We integrated one-time payments using the new docs with SCA that use createPaymentMethod() and not createToken(), so our customers are saved with paymentMethod, not source, like explained here:
https://stripe.com/docs/payments/cards/saving-cards-after-payment#save-payment-method
curl https://api.stripe.com/v1/customers \
-u sk_test_secret_token \
-d payment_method="{{PAYMENT_METHOD_ID}}"
Furthermore, in the migration guide it says to replace createToken() with createPaymentMethod().
In Scenario 2: Charging customers off-session for their initial payment, I saw the following:
To create subscriptions and charge customers off-session for their
initial payment, you need to:
1) Use CreatePaymentMethod to collect payment information
2) Create a customer using the ID of the PaymentMethod you created
3) Create the subscription
4) Set up error handling using handleCardSetup for authentication failures and handleCardPayment for authorization failures
I followed those steps. I don't create a SetupIntent (just like I don't create it in one-time payments and it works in these cases), and receive the error I said before when trying to create subscriptions.
Is it possible to create subscriptions with a customer with paymentMethod instead of source?
(We reuse cards using the customers created with paymentMethod for one-time payments, so it would be very important to be able to reuse the same customer/card for subscriptions, without the need for the user input data in stripe elements or anything of the sort, because it would break our flow for reusing cards)
I was able to solve it by including the payment method in the field default_payment_method.
This field is described as follows:
ID of the default payment method for the subscription. It must belong
to the customer associated with the subscription. If not set, invoices
will use the default payment method in the customer’s invoice
settings.
So I assumed that it would use the payment method I associated with the customer when not defined. It seems it is not happening, tough, so I needed to pass it explicitly (is it a Stripe bug? or creating the customer with paymentMethod doesn't make it the default payment method in the customer’s invoice settings? I will contact Stripe to make sure).
Update (2019-09-23)
I contacted Stripe asking if this was a bug and they replied:
[...] With that being said though, this wouldn't be a bug on our end, rather
expected behavior.
If you're wanting for the Payment Method that you're adding to the
customer object to be used on subscriptions, or invoices, by default
without specifying the default_payment_method when creating the
subscription then you would want to attach the Payment Method and
specify the invoice_settings.default_payment_method parameter when
updating the customer. This information can be found within our API
reference here:
https://stripe.com/docs/api/payment_methods/attach
The parameter to use when updating this can be found on the customer
object itself, here:
https://stripe.com/docs/api/customers/update#update_customer-invoice_settings-default_payment_method
This can also be specified upon customer creation, which can be seen
here:
https://stripe.com/docs/api/customers/create#create_customer-invoice_settings-default_payment_method
Specifying this parameter would indicate that the card being added
would be the default for subscriptions, as well as invoices, so that
the default_payment_method wouldn't need to be specified upon the
subscription, or invoice, creation.
I am using the Java client for Stripe on my backend.
At the moment I'd like to support credit cards and bank accounts (SEPA). A customer is able to add multiple credit cards of bank accounts if he wishes to.
If I got that right, what I want is to use the Sources API, which allows me to add differend types of payment methods.
However, I am not certain how to fetch alle created payment methods (sources) in one call.
Is this possible ?
You can retrieve a list of a specific customer's sources via the GET /v1/customers/{customer_id}/sources endpoint.
https://stripe.com/docs/api/payment_methods/list you can use a customer_id to list all the payment methods saved for a user, assuming you attached a customer_id to the user.