#Gizmo-PaymentIntents

1 messages · Page 1 of 1 (latest)

ruby ibex
#

Hi there! Coupons were designed for Stripe Billing initially and can't be used with PaymentIntents. However, we just released our new Orders API which works with PaymentIntents and Coupons/Discounts: https://stripe.com/docs/orders

iron bridge
#

Thanks, I noticed this, Orders isn’t yet compatible with Payment Links, Subscriptions, Invoicing, and Checkout.. We uses PaymentIntents in part to purchase subscriptions. Does this mean the Orders API won't work for us yet?

ruby ibex
#

Can you tell me more about what you mean with using PaymentIntents to purchase Subscriptions?

#

Are you managing the Subscriptions yourself?

#

Or you are creating Subscriptions within Stripe?

iron bridge
#

I'm generating a PaymentIntent for the first invoice on a Subscription that was created as a recurring billing product in Stripe, attaching the payment elements to the PaymentIntent's key so the payment form shows up in the browser, and then the customer enters their credit card details and checks out. The subscription is created in Stripe and also tracked in my system.

ruby ibex
iron bridge
#

Thank you. Can I also use a coupon on a payment intent for a one-time charge?

ruby ibex
#

Nope, for one-time charges you would need to use the Orders API. Or you would need to use Stripe Checkout.

iron bridge
#

Got it, thanks. Our products are primarily one-time purchases, but we have the option to add on a subscription in which case I create the PaymentIntent for the first invoice of a subscription and add the one-time charge as an additional item on the invoice. To be sure, Stripe coupons can't cover both scenarios, right?

ruby ibex
#

If you create a Subscription, which includes a one-time invoice item, then you can apply the coupon to the Subscription overall so it does apply to both the Subscription product as well as the one-time item.

iron bridge
#

And for the scenario when there is no subscription, Stripe coupons won't work with PaymentIntents, correct?

ruby ibex
#

Correct, that would be a good time to use the Orders API which allows you to use coupons.

iron bridge
#

Do you know if the Orders API ultimately produce PaymentIntent(s) I'd be able to store for reference? I associate each of the orders in my system with the Stripe PaymentIntent it was paid with.

#

Since I need the PaymentIntent to issue refunds, etc.

ruby ibex
#

Yes it still creates a PaymentIntent just like an Invoice does.

iron bridge
#

Is the OrdersAPI significantly different from the PaymentIntents API? I just spent weeks refactoring our application from Braintree to Stripe and was relieved to have it all seemingly working. Needless to say, the idea of refactoring it further gives me pause. 😛

ruby ibex
#

The Orders API provides you with access to more features that we couldn't support on just PaymentIntents like coupons and Stripe Tax. The other option here is that you just handle the coupons on your end using the PaymentIntents API (you create the PaymentIntent for a lower amount if it has a coupon).

iron bridge
#

Thanks. Yeah, I'd opt for the latter but I'm trying to integrate with an affiliate marketing / referral platform that apparently uses/relies on Stripe coupons.

ruby ibex
#

Ah I see.

#

Then yeah... unless you want to redirect to Stripe Checkout (as opposed to using a custom form) you would need Orders

iron bridge
#

Do you happen to have a guide for updating from the custom flow via PaymentIntents to the Orders API? I followed a Stripe guide to implement the custom flow with PaymentIntents that had very specific steps and was very helpful.

ruby ibex
#

That is the overall guide for going from PI --> Orders

#

Which walks you through step by step how you would build this.

iron bridge
#

Thanks. So Orders isn’t yet compatible with Payment Links, Subscriptions, Invoicing, and Checkout. doesn't refer to subscriptions as I'm using them?

ruby ibex
#

Yeah you can't generate a Subscription from an Order currently.

iron bridge
#

Oh, right - the Orders API is for the case where my customer isn't purchasing the subscription

ruby ibex
#

So you would just use them for your one-off payment flow

iron bridge
#

So I'll need to continue to do it the "old way" when subscriptions are involved.

#

Are there plans to deprecate the PaymentIntents API in favor of the Orders API? That is, how long can I expect what I just built to continue to work? 😛

ruby ibex
#

Nope no plans to deprecate it at all! Orders is built on top of PaymentIntents

iron bridge
#

Terrific, thank you. Is there a way to make sure coupons added to a subscription only discount the first charge/invoice and not future invoices?

ruby ibex
#

(That is the default)

iron bridge
#

Terrific, thank you!

ruby ibex
#

👍

iron bridge
#

Hi, another question. When I create the PaymentIntent for the subscription first invoice, is there a way to have the percentage discount coupon apply onto the one-time charge added to the invoice and not to the subscription price itself?

#

For example, if somebody gets a movie streaming subscription with a one-time popcorn shipment, can the coupon apply just to the popcorn?

#

Or would it have to apply to the total amount of the subscription price + popcorn price?

ruby ibex
#

Hmm good question. I think you would need to create a coupon with applies_to and specify the product associated with the invoice item (and ensure the other Price on the Sub was not associated with that Product)

#

I haven't tested that before, but I think it should work.

iron bridge
#

Thanks, bismarck. Are refunds for PaymentIntents created with the Order Api accomplished the same way, i.e. by just specifying the PaymentIntent id, or would I need to change the way my application issues refunds?

ruby ibex
#

Yep refunds are exactly the same

iron bridge
#

Also, does the Order API work with mobile web? Collect payments on mobile using the Payment Element Partially supported

ruby ibex
#

Mobile web, yes. Using our Mobile SDKs, no.

#

It isn't yet supported on our Mobile SDKs

iron bridge
ruby ibex
#

Yes you still need to install it.

iron bridge
#

Oh, why do I need the node library? My app uses PHP

#

That is, my current integration doesn't use it. Is it unique to using the Orders API?

solar saddle
#

I'm not sure I follow what you are asking @iron bridge

#

the stripe.js library is our client-side library, not stripe-node

iron bridge
solar saddle
#

sure but that's a client-side code library

#

you can just load Stripe.js directly if you prefer, both work

iron bridge
#

Ok, so I can continue to just do this instead? <script src="https://js.stripe.com/v3/"></script>?

solar saddle
#

yep

iron bridge
#

Great, thanks for confirming.