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.
Related
Customers on my site use the Stripe Billing portal on user sign up to enter a payment method (card or ACH). What webhook can I use to monitor whether they have at least one active payment method?
I know I can use customer.source.created when a payment method is created and customer.source.deleted when a source is deleted. However a user can initially create two methods and delete one but still have an active method. I just need to know whether they have at least one available
Whenever you receive customer.source.created OR customer.source.deleted events, you typically receive card object as the payload. Since the customer property on the card object is expandable, you may not see it included by default on the card object.
In which case, you'd likely need to retrieve the card object again by calling the API and expanding customer property on it. Once you get the customer ID, you can call this API to list customer's payment methods. This should allow you to see if they have any other PaymentMethods or not.
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!
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 am trying to implement stripe subscriptions in php. I create my subscriptions on the checkout session which payment method is Card and everything works fine. However, I want to check if going one step further is possible. I want to keep the first payment method as Card upon creating the subscription but I want all the succeeding payments to have SEPA payment method. Is that possible? And if yes could you please give me general steps for the overall process?
Just start your subscription with the initial card payment.
Separately, you should follow Steps 1-4 of the guide for setting up Sepa Debit subscriptions.
Then, at Step 5, you can either set the Customer invoice_settings.default_payment_method (API ref) or you can set the default_payment_method (API ref) on the Subscription, depending on how you choose to set things up. This will replace the payment method to be used for future renewal payments on the Subscription.