#Greggles - gift subscriptions
1 messages · Page 1 of 1 (latest)
Hey @worldly lynx, sorry if this question seems basic, I'm just new at this. If it wasn't apparent, we're using Stripe's API.
Ok, there are a bunch of pieces here. I'd like to break in down into understanding what you're actually having trouble with.
You talk about both checkout payments (from guest or known customers) along with gift payments and time limited subscriptions (versus default perpetual).
Can you be more precise about what is not doing what you expect, or what you can figure out how to do?
To be more precise, we have one product with several prices, each corresponding to a recurring subscription period(one year, one month etc.). All that works fine. We simply want to offer anyone the ability to gift an access period to anyone else so I created 2 new prices gift_six_months and gift_one_year which are non-recurring charges. So very basically I guess I want to know how.
Do I create a customer first, then charge the price, or create a charge object and associate a Stripe customer ID if I have one.
It sounds like you want two customers here, the gift giver and the recipient
Sort of. The recipient would not have a Stipe account, only an account in our database
the gift giver is a customer with a payment, the recipient might be a stripe customer with a subscription that gives access
If you don't intend on getting payments from the recipient, you may not need stripe objects at all
but creating a subscription for them (either with a $0 price, or a 100% discount for one month/year etc) then you have the option to getting a payment method from them to continue the subscription
To clarify language, none of your customer need to have Stripe accounts, only you have a stripe account. your account might or might not create customers for them inside your account, though.
(or accounts in your system)
Greggles - gift subscriptions
Thanks for the language clarification. Actually if the recipient was already a customer we'd want to apply the subscription period amount to their customer ID, after their existing period ends.
That's a bit tricky, and you'd need to manage the reconciliation yourself, but you can do this with subscription schedules:
https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#existing-subscription
So eg you could have the subscription continue to the end of the billing period, then transition to a prepaid gift period, then switch back to a regular paid price etc
Thanks for the suggestion. You’re saying we’d create a customer if for the recipient, rather than the gifter. Great idea.
I think you'd do both myself, but the gifter customer is optional. You must create a customer in order to create a subscription (eg for the recipient), though.
To clarify, we don't want to create a recurring charges subscription for the recipient, it would be a one time charge from the gifter for access to our service for a set amount of time. After that time expires the recipient could subscribe on their own, if they didn't have a StripeID, or continue their own recurring charges subscription if they were an existing customer.
OK sure that works too. If there's no payment needed/expected from the recipient, you likely dont need a customer/subscription at all then, and you can track their access rights in your own system
Yes,
And only the gifter would have a payment (and possibly a customer object)
Possibly but not a requirement then.
Sorry, that was a question 🙂
We could just create a payment without a customer object for the gift and then manage the subscription access in our own system. We could associate the customer ID with the payment if we had one but we don't need to do that. In that case it would be just a one-off payment?
We would use the charge object API
https://stripe.com/docs/api/charges/object
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Correct - these are not strictly related from Stripes perspective, that's your system's concept connecting them
No don't use charges - that's a legacy API
Payment Intents are the current API, and there are several ways you can integrate:
1/ Custom payment form on your own site using Payment Intents directly (code level: high)
2/ Prebuilt payment form hosted by Stripe using Checkout where you manage sessions yourself (code level: medium)
3/ Use Payment Links to redirect to Checkout automatically using a normal HTTPS url (code level: zero)
Great info, thanks for that.
If you know how you want to do it i'm happy to share more info, or you can explore the options in the docs:
Fully custom: https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=elements
Checkout: https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=checkout
Payment Links: https://stripe.com/docs/payments/payment-links
We're already using fully custom forms for our subscriptions so the elements documentation should work for me. Thank you again. You've been really informative and helpful.