#gagansuie-payment-links

1 messages · Page 1 of 1 (latest)

magic thornBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

wheat thorn
#

The body of an invoice.paid event will be an Invoice object. invoice.customer will have a customer ID.

#

PaymentLinks for Subscriptions will always create a customer object

random python
#

wait, so if we create a customer object with the email and userId in metadata manually. will it create another one?

wheat thorn
#

Can you clarify what "it" means in this scenario?

random python
#

PaymentLinks for Subscriptions will always create a customer object

#

will that create another customer object?

wheat thorn
#

That's correct

#

If you'd like to use a Stripe-hosted way of collecting payments for an existing Customer object, I recommend using Checkout instead of PaymentLinks

magic thornBOT
#

gagansuie-payment-links

random python
#

ok one moment ill investigate that flow

#

where do i find documentation for that? i dont see it in the stripe dashboard

#

nevermind, i got it!

random python
#

so if i want to stick with payment-links, is it the email that comes back that distinguishes the user?

#

email in the customer's invoice.paid webhook.

wheat thorn
#

Not exactly as, like you said, someone could use the PaymentLink multiple times to create multiple Subscriptions with the same email address. A new Customer object would be created for each of those Subscriptions

random python
#

ah, so setting the 1 subscription per user is only for checkout flow.

wheat thorn
#

That's correct

#

Depending on what you're doing and what you want the ideal flow to be, you could use the Pricing Table and use customer sessions to tie a Subscription to an existing Customer: https://stripe.com/docs/payments/checkout/pricing-table#customer-session

This would require you to have users log in/authenticate in some way prior to landing on the Pricing Table so you could create a Customer and Customer Session, or create a Customer Session for an existing Customer

random python
#

right, i went down that rabbit hole already. it didn't offer a way to remove subscribing to "FREE" tiers.

wheat thorn
#

What do you mean by "free" tiers?

random python
#

we dont want the free tier to be subscribable.

wheat thorn
#

This should be customizable when you create/edit the Pricing Table.

random python
#

so we're redirecting to dashboard if the user is already subscribed. so they shouldn't be able to subscribe twice using payment-links.

#

after a user subscribes, is there an id we can use to notify our backend that this specific user is subscribed?

#

in webhooks invoice-paid.

wheat thorn
#

I think we're back to the beginning. This isn't possible with PaymentLinks. It's kind of possible with the Pricing Table but you would need to handle the creation of a Customer Session before allowing users to access the Pricing Table (which also means they'd need to authenticate up front)

#

If you don't want to use the Pricing Table, I recommend using Checkout instead. There's a bit more development work compared to Payment Links but that should take care of what you need: limiting users to one Subscription, creating Sessions for existing Customers

random python
#

but then what is the significance of offering payment-links if you dont know who made the paymnet to give them the service they paid for?

#

i just need to know who made the payment.

#

the invoice object has customer_email. so im assuming i could use that to distinguish the user?

wheat thorn
#

but then what is the significance of offering payment-links if you dont know who made the paymnet to give them the service they paid for?
The use case for PaymentLinks is to offer a quick, no-code way of accepting payments (for one-off items or subscriptions) where you don't need to place many more restrictions on who can use that link.

#

Yes, you can use customer_email on the Invoice object to determine who paid

random python
#

great! so we can redirect a user to the dashboard when they are subscribed.

wheat thorn
#

By dashboard, you mean your own app's landing page, right?

random python
#

for them to make changes if they need to

wheat thorn
#

How are customers landing at the customer portal? Are you creating portal sessions via the API?

wheat thorn
#

@random python Do you need more help? If so, could you describe in full which products you want to use together? So far, it's the customer portal and PaymentLinks but it's not clear to me if you want customers to only be able to have a single Subscription at a time.