Lets say I have a new customer who is checking out and wants to store their card for future use. If I'm reading the docs right, I need to make separate calls out to Stripe, one to create the customer with the card and another to charge the card.
Considering the endpoint for creating a charge accepts either a token or a dictionary for the card, I'm suprised the same isn't true for the customer parameter.
I have tried sending a dictionary for the customer in a create charge request to no avail.
Am I forced to make two calls? And if so does Stripe accept feature requests?
Q: Am I forced to make two calls?
A: Yes, you're forced to make two calls to the Stripe API upon creation of a Stripe customer.
If a customer already exists in your database, you only need to make one call to the Stripe API, as shown below. Here, we're creating a charge and passing the retrieved customer ID:
Stripe::Charge.create(
:amount => 1500,
:currency => "usd",
:customer => customer_id
)
Making a charge is outlined here in Stripe's documentation: https://stripe.com/docs/tutorials/charges
Q: And if so does Stripe accept feature requests?
A: I'm not 100% sure if Stripe accepts feature requests across all languages, but it is available for Go: https://github.com/stripe/stripe-go/blob/master/README.md#development
I'd double check the Development section of each README or contact a developer at Stripe directly (freenode #stripe)
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!
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 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 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.