#birdy247-invoiceitems

1 messages · Page 1 of 1 (latest)

crisp crypt
#

Hi! I'm not sure if we have a documentation page specifically for that. Let me have a look.

next sky
#

thanks 😊

crisp crypt
#

Basically you add the invoice item to the customer, and then the next invoice for that customer will automatically include that invoice item.

next sky
#

awesome

#

Thats great

#

And will it all fall under the same payment intent?

crisp crypt
#

When the invoice will be created, it will automatically take all invoice items, and then the invoice will have a single PaymentIntent.

next sky
#

ok great

#

Can I ask you another question about subscriptions?

crisp crypt
#

Sure!

next sky
#

So right now, we work with this flow

#
  1. Create payment method using stripe elements
  2. Send that to our backend and create customer
  3. Create a subscription
  4. Get the latest invoice and check if payment intent requires action
#

Is this the most logical way

#

Context.. We currently have a platform that lets people make one off charges of setup a subscription. We want to keep the same flow. So right now, for one of charges, we do the following

#
  1. Create payment method using stripe elements
  2. Send that to our backend and create a payment intent with confirm = true
  3. If the payment intent requires action, send this to the front end
#

But we want to change it to:

  1. Backend makes a payment intent
  2. Send this to frontend
  3. We confirm the payment intent on the frontend
  4. Use webhooks to ensure the payment works
#

So I am wondering how we can implement this new flow whilst still retaining the same flow for subscriptions

#

Can we create a customer and subscription and then pass the payment_intent to the front end before we create a payment method?

#

@crisp crypt ?

uncut valley
#

Can we create a customer and subscription and then pass the payment_intent to the front end before we create a payment method?
yes you can

#

sorry I'm taking over the thread, so I had to read to have some context

next sky
#

Thats awesome

#

So we can keep the same flow where a payment_intent is always sent to the front end from our backend

#

rather than creating payment methods and then sending that to the backend

#

payment_behavior

#

Is this the key field

uncut valley
#

rather than creating payment methods and then sending that to the backend
this is our new recommendation yes

next sky
#

so if we create a customer and a subscription and then retrieve the payment_intent, how do we then get the payment method added?

uncut valley
#

using the client_secret generated while creating the PaymentIntent. You could pass that to either the PaymentElement or CardElement on the front end

next sky
#

Ok, and then use the confirm function

uncut valley
#

yes exactly

next sky
#

Will stripe then link everything up behind the scenes

uncut valley
#

yes exactly

next sky
#

Just to confirm my thinking

#

The To Be flow

#

Also, we have a concept of users and members. A user can have many members. We currently map a user to a stripe customer. Would it make more sense to map a member to a stripe customer instead?

#

Like, can we have to customers with the same cards? We have run into problems with this in the past

uncut valley
#

It really depends on your use case

#

are you using the same payment method for all members of a user?

#

do you want to have all the payment under one customer?

next sky
#

they may chose different payment methods

#

I think the reason we map it to a user, is because stripe returned an error saying we cant have the same payment method on 2 different customers

uncut valley
#

members can't use each other's payment method, right?

next sky
#

No

uncut valley
#

in that case you should separate them into different customers

next sky
#

but what about the issue of stripe not allowing the same payment method on 2 seperate customers?

#

because its highly likely that will happen if its a husband and wife etc..

uncut valley
#

you need to recreate the payment method

#

by doing another SetupIntent or PaymentIntent

next sky
#

right, so it is possible to have 2 customers with the same debit card for example?

uncut valley
#

yes if they are created as two different payment methods

next sky
#

which they would be if we created a new customer and subscription presumably?

uncut valley
#

but you can't use the same Payment Method id pm_xxx for two different customers

#

which they would be if we created a new customer and subscription presumably?
yes

next sky
#

im sure it was something to do with the cards finger print, but we shall see

uncut valley
#

I don't think it is related to that

next sky
#

ok cool

uncut valley
#

In your old flow, you were creating the Payment Method and then attaching it

#

which is problammatic if you try to attach it to multiple customers

next sky
#

We are hitting a few occourances of people being charged twice. Do you think this new flow will solve that

uncut valley
#

but if you use the PaymentElements and the card is the same it would matter

#

We are hitting a few occourances of people being charged twice. Do you think this new flow will solve that
Do you have any examples?

next sky
#

It happens when we have a surge of bookings

#

People say that after they enter their card details, the page just continues to loa

#

load*

uncut valley
#

Maybe you're capturing twice in the old flow

next sky
#

The payment is successful on stripe but we never get a response (we are not using webhooks in that flow)

#

I am hoping the new flow will greatly improve that

uncut valley
#

could you share PaymentIntent ids pi_xxx or Charges ch_xxx or even Customers cus_xxx for that particular scenario?

next sky
#

let me find 1

uncut valley
#

take your time

next sky
uncut valley
#

I will take a look

crisp crypt
#

Hi! Can you clarify what is the issue with the two PaymentIntent you shared? Both where created by your integration and with different amounts.

#

Technically they have been created by the platform account.

next sky
#

This is because the first one was made, and the customer never got a response, so they refreshed the page and added anoter item then paid again

#

Yea, thats us

crisp crypt
#

Thanks for the clarification. But what do you mean by "the customer never got a response"? This PaymentIntent (pi_3KHv6fJQGpnjAZ8z0DcwjSFB) was created on your backend successfully.

#

So from our point of view everything worked as expected.

next sky
#

Can you see the response you send back?

#

And can you see how quickly it came back after the request was made?

crisp crypt
#

And can you see how quickly it came back after the request was made?
Let me check

next sky
#

We also have another fairly complex use case we are looking for advice on.

#

Assuming we have changed our flow to the new way stripe suggests i.e. creating the p_i before the page loads and then confirming on the frontend + using webhooks

#

We are a platform and use standard stripe accounts with direct charges.

#

We have scenarios where there are multiple connected stripe accounts that need paying from a single transaction

#

If using destination charges, this would be easy, but for legal reasons, we dont want to do that

#

So, the question comes.. How is the best way to do this whilst still retaining the stripe recomended approach

#

Right now, we create a customer on the platform and share this with the invovled platform accounts

#

But this then reverts us to having to create the payment method on the front end and pass it to the backend (which we now want to avoid if possible)

crisp crypt
#

And can you see how quickly it came back after the request was made?
Unfortunately this is an old PaymentIntent, so I don't know how long it took on our end. I could check if you have a more recent PaymentIntent with this issue.

next sky
#

How recent?

crisp crypt
#

less than a month

#

We have scenarios where there are multiple connected stripe accounts that need paying from a single transaction
So the customer would pay once, and then you would send the funds to multiple Stripe account? For this the recommended approach is separate charges and transfers https://stripe.com/docs/connect/charges-transfers

next sky
#

But we dont want the charge to happen on our account

#

We want the charges to happen on the connected stripe accounts

crisp crypt
next sky
#

Where would chargebacks be made?

crisp crypt
#

On the platform account I believe.

next sky
#

Yea we dont want that

#

And also, presumably it could take a few days for this transfer to show in the connected acount if we use source_transfer (which we would)

#

source_transaction *

#

In the past, we have created a shared customer

#

any ideas?

crisp crypt
#

Got it! Let me reread your previous message to make sure I understand what you are trying to do.

#

So what happens when a customer pays right now? It's a direct charge on one of the connected account? Or you create multiple direct charges on multiple connected accounts?

next sky
#

multiple direct charges

crisp crypt
#

You could create a SetupIntent on your backend (with your platform), confirm the SetupIntent on the frontend, this way you have a payment method on the platform. And then your clone that payment to each of the connected account.

next sky
#

Do we need to create a customer on the platform account for that?

crisp crypt
#

If you plan to clone the payment method on multiple connected accounts, then yes you need to need to attach the payment method to a customer on the platform account.

next sky
#

Right

#

So create the customer and setup intent when the page loads, confirm the setup intent on the front end?

#

At what point would you recmoned that we then create the payment_intents on connected acounts?

#

While the customer is at checkout or at some other point?

crisp crypt
#

So create the customer and setup intent when the page loads, confirm the setup intent on the front end?
Yes!

#

At what point would you recmoned that we then create the payment_intents on connected acounts?
It's up to you. Once you have the SetupIntent you can either charge the customer on_session or off_session.

#

Note that when charging off session, the payment may fail if the payment method requires authentification (like 3DS). When that happens, then you need to bring back the customer on your website and confirm the payment.

next sky
#

Ok, so best to do that while they are at the checkout

#

When confirming a setup intent on the front end, can we be confident this was done from the response?

crisp crypt
next sky
#

as a webhook?

crisp crypt
#

setup_intent.succeeded is a webhook event yes.

next sky
#

right

#

Ok, this could be an interesting flow!

#

Thanks for your help

crisp crypt
#

Happy to help 🙂

next sky
#

just a quick one

#

would we create the customer or setup intent first?