#simonsayscode-promo-code

1 messages · Page 1 of 1 (latest)

sand quest
#

ideally, after i apply a discount/coupon to an existing subscription, i would be able to regenerate the current outstanding invoice, but so far i've found no way of doing so.
Yes, this is expected behavior - this is because creating a Subscription will automatically finalize the resulting Invoice (at which point you can't make any modifications to it).

Instead of what you're currently doing (voiding the existing subscription) - I'd recommend utilizing the upcoming invoices endpoint (https://stripe.com/docs/api/invoices/upcoming) to show your user a "preview" of what the created subscription will cost when used with a specific promo code. Once they've confirmed they want to use a specific promotion code, then they can continue on to payment (at which point you'd create the subscription so you can get the PAyment or Setup Intent ID to be used with the PAyment Element)

Stripe API reference – Retrieve an upcoming invoice – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

olive osprey
#

are you saying that there should be a promo code input first, before any payment input is displayed?

#

the goal was to recreate an in-house version of the stripe checkout page, where it has the promo code input alongside the payment method collection

unknown.png
sand quest
#

Checkout implements this VERY differently though - it's not using Payment Element (although they look very similar). It uses upcoming invoice for the left half of the screen (the promotion code and such), but the right hand side is not actually using Payment Element. Checkout has their own flow where they create a PaymentMethod obejct from the payment details provided, and then continue on with creating the subscription/pi and confirm it

olive osprey
#

i see

#

so i get what you're saying re: updating the UI with the preview, which doesn't at the moment apply the coupon to a subscription, but i thought that the Payment Element UI needs a paymentintent/client_secret in order to initialize. is there a way you suggest to collect the payment info in advance, and send it up, along with the coupon for subscription create, before the subscription is actually created?

#

or to rephrase, how can i create a PaymentMethod UI that's not the PaymentElement UI (but looks incredibly similar)

sand quest
#

Yeah, since the PAyment Element doesn't support the flow you're trying to build, the closest you could get would be to utilize the individual elements (like Card Element) which DO allow you to create Payment Methods and don't require a Payment/Setup Intent in order to work

olive osprey
#

the card element only features the Card itself, right? no name or other related information?

#

i'm confused why both suffice for payment, if one is significantly less information for the user to enter? ¯_(ツ)_/¯

sand quest
#

The Payment Element w/ card doesn't collect "name" either - that's another thing that's specific to Checkout. The only additional field that the Payment Element for card accepts that the Card element does not is "Country"

olive osprey
#

okay so i'm poring over the https://stripe.com/docs/payments/accept-card-payments?platform=web&ui=elements&html-or-react=react guide here for the CardElement and i see that this

  // CREATE SUBSCRIPTION WITH THE PROMO CODE AND THEN RETURN BACK THE CLIENT SECRET FROM THE AUTOGENERATED INVOICE
    const result = await stripe.confirmCardPayment('{CLIENT_SECRET}', {
      payment_method: {
        card: elements.getElement(CardElement),
        billing_details: {
          name: 'Jenny Rosen',
        },
      }
    });

is where i'd have to fetch the client secret from the invoice created (at that time) for the promo to apply at "checkout" time

Accept a card payment

Securely accept card payments online.

#

but if a promo is 100%, doesn't that automatically set the subscription as active ? or maybe that doesn't quite matter because the confirmCardPayment will succeed and the invoice will be satisfied, in that same step?

sand quest
#

Yes, that'll automatically set the subscription as active, but in those cases we do provide a Setup Intent that can be used to validate the payment method

olive osprey
#

(looks up setup intent documentation now)

#

sorry i'm being dense but can you walk me through how the code i referenced from the CardElement documentation would need to change, in order to accommodate promo codes that could be 100% or just amount off?

#

i guess what i'm unclear on is, in the cases of the 100% off, i guess the setup intent saves the card for future usage since it's not charged in that moment -- but in the case where we don't know if it's 100% off or only a smaller % off, does the client_secret returned by SetupIntent allow the

    const result = await stripe.confirmCardPayment('{CLIENT_SECRET}', {

to charge the customer at that time?

#

btw, this has been very helpful already, i feel i'm much closer to my goal than i was an hour ago, but there are just a few more things i'm still unsure about

sand quest
#

Sorry to back up for a second - there's multiple ways to do this with the CardElement. Really, the code you linked to wouldn't need to change much - as you have in the comment, right before you call stripe.confirmCardPayment you'd create the Subscription (with latest_invoice.payment_intent expanded). Then you'd use the client secret for that Payment Intent and use that to confirm the first payment of the subscription. We also have specific guides on how to integrate with Subscriptions using the card element (which you can find here https://stripe.com/docs/billing/subscriptions/build-subscriptions?card-or-payment-element=card-element, you just have to select "Card Element" instead of "Payment Element")

#

For the 100% case, you would use pending_setup_intent and use it with stripe.confirmCardSetup, not confirmCardPayment. The Setup Intent will NOT make any charge for the customer - it just validates the card and makes sure it can be used in the future

olive osprey
#

so the code would call confirmCardSetup or confirmCardPayment depending on the code's knowledge that this would be a $0 invoice vs a non $0 invoice?

sand quest
#

correct (or based on the presence of pending_setup_intent vs latest_invoice.payment_intent

#

I need to head out, but if you have any follow up questions @kind pasture can help!

olive osprey
#

thanks so much! i think i have enough to make an earnest attempt at this