Validate that Coupon in Stripe!

Hey, I was wondering if there's any advantages to using the stripe coupon vs building a coupon entity in symfony? It seems that you have advantages to building a coupon system within symfony as it allows this feature to be customized (user can only use coupon once, coupon tied to specific products only, can attribute coupons to users / "sales people" for commission report generation etc). Is there any advantages to using stripes coupon system? I'm very curious to know *curious pikachu face*

Hey Cameron,

Basically, you got this right! Stripe coupon is something more low-level, if you create a Coupon entity in your project - it's more like a wrapper around that low-level thing that brings you more flexibility, you can store the coupons in your DB, list them, view orders with attached coupons, easier apply some custom validation logic to coupons, etc. And all that you can do without executing any API to the Stripe server, so it's also a good performance boost on your app side. But that's not a requirement, so you can skip this abstraction and create coupons directly in Stripe if you want, but that might be less flexible and convenient. But it's totally up to you and depends on your specific project.

Cheers!

Hello, if I manage my coupons in database, and I also want to update them at the same time as they are on Stripe, what way do you recommend?

Should I use a "coupon.updated" webhook and check if the number of uses has decreased and if it has expired, then compare it to that stored in the database and make the modification?

Hey Kiuega!

Hmmm. We store coupon data locally also here on SymfonyCasts. We did it this way:

A) When you create a new "coupon" in our system (via an admin area) we only store that coupon data locally. We do NOT notify stripe about it at all.
B) On checkout, if a "coupon" is applied to the cart, *right* before we create the new Order in Stripe, we generate a random coupon code for the correct value in Stripe and attach it to the Order.

Because of this, we do all the management & validation of the coupons. For example, if a coupon can be used only 1 time, we store that info in *our* database and then do that check ourselves before allowing the coupon to be applied on the checkout page. It gives us more control, but it means we're managing a lot more stuff and aren't leveraging the coupon functionality that Stripe is giving us.

So... the best path depends on your goals. The easiest thing to do is let Stripe handle everything and make API calls to it. So the question would be: *why/8 do you want to have a local storage of coupons?

Cheers!

Okay thanks for your info! So my answer to

*why/8 do you want to have a local storage of coupons?

is just : "Why not ?"

Imagine that we manage several sites. It is true that going through Stripe directly to manage everything is easy.
But just for "aesthetic" reasons, being able to manage this directly from our site's admin interface would be just as pleasant!

For my part, I created a "Coupon" entity, and a "CouponService" service. And I set up an interface really similar to that of Stripe and I store everything in a database, but parallel to that, I also store on Stripe API.

Now the point that I have to develop is that of "updating the coupon in my database when it is used or expired". I imagine that using a webhook will be more profitable for me

Hey Kiuega

If the point of doing that is to exercise your coding skills, then that's ok. If not, then, it's an overkill (unless you have a specific reason to do so) because you will have now to keep in sync both systems, yours and Stripe.

Cheers!

In fact the main goal of this work is as follows: If in the future I have several sites online and which each have their plans, their products, their coupons, it is easier to manage it directly from the site in question .
Because otherwise, let's say I use the same Stripe account for all of my sites. I will have products, plans, coupons, but I will not find myself there, I will no longer know which one is for which site.

Finally, in my opinion, an advantage to manage also in database is the fact that if I have several sites again, and that I have a webhook which is sent, it will be sent to all my sites for which I will have configured the webhook. And in this way, in backend I will only have to intercept the webhook in the WebhookController.php and only establish a treatment if it is indeed an object belonging to my site, and not to another. You see ?

EDIT : And last thing of why I also want to have a full panel on each site rather than using Stripe directly: A case where I create an application for a company. They will therefore have their own Stripe account. But who is going to create the subscription plans, add products, and coupons? Maybe not the same person, because that would mean that they would all have access to the company's Stripe account. If they are assigned a role on the created application, then they will not have access to all the commands

Ohh, so you DO have a real reason to do the admin panel. In this case, it makes perfect sense to me :+1

Hey Kiuega!

That all makes sense :). Here's my advice then: rely as much as you can on webhooks. For example, here is one "pretend" way you could do it, just to highlight what I'm talking about. You could, in theory, rely 100% on webhooks to update your local database. So, when a user creates a new coupon code in your system, you DON'T immediately save it to your local database. Instead, you only make the API request to Stripe to create the coupon code. Then, when the webhook for that creation "fires", you receive it, and add that record to your local database. The same thing would happen when the user edits a coupon code: you wouldn't save the data locally on submit - you would just send the API request and then allow your webhook system to update the local database. This is the simplest and cleanest way to get this all working: rely 100% on webhooks to synchronize your local database.

The reason this is only a "pretend" idea is that, when a user creates a new coupon code in your system, if you don't save it to your database immediately, then there may be a few seconds delay before the user sees it, which would be super confusing :). But, you can still use the same philosophy: on submit, first send the API request to Stripe. Stripe will return some new "Discount" object in JSON. You can pass that to the same code (more or less) that handles the "discount created" webhook so that you don't have duplicated logic. The only trick then is that, in your "discount created" webhook logic, you'll need to add code to avoid adding a new row in your database if it is already there. With this setup, you could still create a coupon directly in Stripe's interface, and it would synchronize back to your system perfectly.

One thing to watch out for is this: sometimes Stripe webhooks are SO fast that they are delivered even while the code that sent the API request is still running. This is easiest to see in an example with some fake code:

$discountData = $stripeApi->createCouponCode('YAY_FOR_DISCOUNT', 2000);
$discountEntity = new Discount('YAY_FOR_DISCOUNT', 2000);
$entityManager->persist($discountEntity);
$entityManager->flush();

In this example, you expect that things will happen in this order:
A) You send the API request to stripe to create the discount/coupon
B) You save the Discount to your local database
C) ... some time later, the webhook is received from Stripe about the discount creation.

But we've found that sometimes (C) can happen between (A) and (B). You need to write your code to allow for this. OR, you need to do (B) first (save the entity to the local database) and then (A). That's what I'd recommend. And it will work great, as long as your "discount created" webhook logic is smart enough to avoid inserting a new row in the database if it sees that the YAY_FOR_DISCOUNT Discount is already there.

Phew! Anyways - have fun :).

Cheers!

Wow thank you very much for all this information!

Regarding the way of doing things (A), (B), (C), yes you are entirely right!

And regarding plans and products I would also have a question.
If I want to manage this in a database, then in the case where I delete a plan as well as its product, since the users who use this plan can continue to use it, it means that they are not actually deleted from the database. Stripe data right?
To reproduce this diagram, when I delete a plan or a product, I must simply say in MY database that the object goes to "inactive" status? Or can I still delete it from my database too?

I'm not sure if you would be able to delete the plan and product if there is a user related to it. If you see it from the database point of view, you will have a record in other table relating to the product/plan id that you want to delete, hence, the delete query will fail. I think your best choice is to do what you said, inactivate a plan or product, so nobody else can consume it anymore

Cheers!

is there a warning attribute for an addFlash function? i only see success and error :) would be nice if i can get it like those 3 from bootstrap :)

Hey Blueblazer172

Flash messages works as bags, whenever you add a new flash message it's stored to the name you chose, so then you can loop through them and do what you need, in your case, rendering an element with a bootstrap class "alert-warning", you can check all alert types here:
http://getbootstrap.com/com...

Have a nice day!

thanks for replying. im familliar with the bootstrap alerts :)

but what i mean is this:

 $this->addFlash('error', $error);```

to something like this:

$this->addFlash('warning', $error);`

is that possible ?

Actually you can choose whatever name you want, is just for your convenience, if you are lazy (I mean wise) like me, you could name those messages with the same name as bootstrap class and loop through them like this:

{% for type, messages in app.session.flashBag.all %}
  {% for message in messages %}
    <div class="alert-{{ type }}">
      {{ message|trans }}
    </div>
  {% endfor %}
{% endfor %}

Then you can add more logic if you have other kind of messages