I have an order form that uses a Stripe payment integration and I also want to add a checkbox for a option to "Pay Later" which will be an invoice directly to their company and in turn it will cancel the need for the Stripe payment. The problem i'm having is the Stripe library passes validation for card info and it stops the form submit if anything is empty or invalid in the Stripe integration.
Stripe has a guide for setting up future payments which covers a lot of scenarios. The basic, high-level steps are:
Create a Setup Intent
Collect payment information
Use the Setup Intent to set the payment information up for later use and attach it to a Customer object in Stripe
Once that's done you can then charge/invoice the Customer later.
Related
We have our own payment processing system. This takes a customer token from Stripe's response after initially checking out, and uses it each month to charge the customers card.
We want to do similar for mobile wallets, like Apple Pay.
However, Stripe docs indicate that it only returns a token which is 'single use', so the customer would have to authenticate the payment each month:
We aren't able to integrate with Stripe's 'subscriptions' service, as we'd have to migrate across entirely to Stripe - which we can't do.
So as a result, is it possible to get a reusable token - or does the 'subscription' it's referring to mean that we can get a reusable token in the same way as a standard card payment?
And by reusable token - I mean, the customer doesn't need to authenticate the payment each month.
Hope that makes sense!
When you accept an Apple Pay payment, you can still save the underlying card for future payments. This will then work whether you use Billing (their recurring payments product) or just create one-time payments yourself.
The call out from Stripe in their docs is more around the rules coming from Apple. If your customer is checking out in your application or website, you are expected to show them the Apple Pay UI to confirm the payment again instead of using a previously saved card. On the other hand, if you are doing recurring payments, you can use the previously saved card for future payments.
The integration itself is fairly straightforward. You would create a PaymentIntent server-side and collect the card details client-side whether via Apple Pay or not. Since you want to save card details for future payments you would also pass setup_future_usage: 'off_session' on the PaymentIntent creation. After a successful payment, a PaymentMethod of type card would be attached to the customer with the id pm_123 and you could use this in future recurring payments.
This flow is covered in Stripe docs here and also applies to Apple Pay and this section covers how to make the future payments.
Quite suprisingly, it is not possible to automatically generate an invoice after as successfull checkout session with Stripe.
An invoice must always come before a payment in the stripe system.
I am left with having to recreate the invoice through a bunch of API calls fetching the PaymentIntent or the CheckoutSession that was just performed to recompute the data for the invoice and mark it as paid (not even sure I can retrieve everything I need)
This seems quite hacky... Is this the right way to do it or shall I just handle invoicing outside of stripe (quite annoying too) ?
just want clarify if you need Invoice or Receipt, because they are two different things
Invoice is something you send to customer to ask for payment (before payment)
Receipt is a proof of succeeded payment (after payment)
My understanding is that the payment is already collected upon a succeeded checkout session, so you probably want to send receipts to customers. To enable email receipts, you can go to Settings -> Emails and tick the Email customers about Successful payment box. Please note that emails won't be sent in test mode.
Let me explain a solution that you can use to generate invoices after payment in stripe. This solution is based on Zapier connectors.
There are three systems that we should connect.
Stripe
Zapier
Plumsail Documents
First, you have to set up a Stripe connection to Zapier. Go to Zapier, create a Zap, find the Stripe connection, and select "New Payment" as the trigger event. Then, connect your Stripe account with Zapier and make a test in Zap. If everything ok, go to the second step.
Second. After you have done the Zap connection for Stripe, go to Plumsail Documents, create the process, and make a template for your invoice.
Third. Set up a Plumsail Documents connection to Zapier. Go to your Zap (where you have made the connection to Stripe before), find the Plumsail Documents action, and set the Start Process as Action Event. Next, you have to select your process and match output data from Stripe payment with your invoice template in Plumsail Documents.
It seems a bit complicated, so you can read the article with a more detailed description of this solution. Also, there are screenshots for all processes.
As a result, you will get a fully automated custom invoice generation whenever you will get a payment in Stripe.
Max, product manager at Plumsail.
I'm trying to integrate the Docusign eSignature API with Stripe.
I've created a Quickstart application and have successfully run through the process, signing the contract and making a test payment.
However, I noticed that the payment in Stripe does not have a customer object attached to it:
I'd like to know if it's possible to specify a customerId, or create one as part of the process. I did notice that the PaymentDetails constructor accepts a customerId parameter, but I could not see any relevant documentation for this, and specifying it in my request didn't seem to make any difference.
Any advice appreciated.
Thanks
Dan,
For regular payments that are one time and right away - DocuSign will not create a customer record. This is "by design" and is meant to support quick payments without any customer record.
You can set recurring/future payments and then you'll get customer records when you set the gateway. If you want, your recurring payment or future payment can be just one time in the near future and then you can achieve what you want and get a customer record.
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.
I've making a SaaS that allows customers to subscribe to a plan, and use coupons at the checkout stage. The coupons give the customers X% off for X months, and by default, everyone gets a 7 day trial when they subscribe.
What is confusing me is the documentation. In one section it says that you should create SetupIntents to take a payment and elsewhere it says to use tokens.
I'm in the middle of coding the payment flow, but I just wanted to check to see if my logic and understanding is correct. Could anyone validate the below?
Customer enters card number and coupon
Call Stripe, get token for card
Send token and coupon to server
Create Stripe customer with token
Create Subscription with discount and pass customer ID
What has now happened is an authorisation attempt was made. If SCA is required, then the subscription status is incomplete and the latest invoice payment intent status requires action.
At this point, I can redirect my user to the SCA Flow using handleCardPayment() to prompt 3DS, and once complete the subscription status is then active.
If the invoice payment fails for any reason, then the subscription state is incomplete and the payment intent requires has a payment action required status. At this point, I should present my customer with the React Elements form again, and call the stripe.invoices.pay endpoint with the new card token
Going forwards, all subscription charges should not need further SCA approval, however if the customer changes plan or the bank requests it, then I can point my user back through the SCA Flow process
A diagram of the flow is here: Green is UI, Orange is Server, Blue is Stripe
Is there anything I have missed or misunderstood here? I've been reading about creating SetupIntents and PaymentIntents, but I'm not sure I need this?
If you are creating subscriptions using the Stripe Billing product they handle creating the PaymentIntent(if you are taking a payment immediately) or a SetupIntent (if you are setting up a trial or metered billing). All that you really have to do different is handleCardPayment (for payments) or handleCardSetup (for setting up trials and metered billing). This section in the docs is pretty good.
If you are not using billing they have a video on their Stripe Developers Youtube channel which may help clear up any confusion.
Hope this helps :)
Welcome fellow sufferer, cards and tokens are implemented in Stripe Charges API which is not SCA compilant. If you want use Stripe for payments inside the EU you should use payment intents.
Card tokens are also allowed for creating payment intents.
But if you want reduce the number of necessary authentications you should use setup intents (with usage = "off-session") for creating payment methods and not card tokens.
I have a lot of old customers who have still registered with the Charges API. I use the following strategy:
New customers always register via Setup Intents and Payment Methods.
Old customers use the Charges API until their tokens become invalid. Then they must also use setup intents and payment methods.
Of course, the customers do not notice much of it.
In summary, I would always use payment methods and setup intents for new customers and card updates. Only with the setup intents can you ensure that your customers have to authenticate themselves as rarely as possible.
EDIT: The crucial point is off-session payments that occur with subscriptions. The Stripe procedure is described here: https://stripe.com/docs/payments/cards/saving-cards#saving-card-without-payment