What is the best setup for a subscription system?

Sounds like Laravel Spark might be just the thing for you (when it's released).

I agree. You can manually create using Laravel Cashier and also getting a Stripe account. This is alot of work and takes a good amount of engineering skills. Laravel Spark should be released soon, like this month. I am working on a site and was just about to go about creating the subscription section but I think I am going to save the headache and just integrate Spark so I can worry about my actual application. I am checking a few time a day for its release lol. I cant want.

@DanSmith @mcprogramming Thank you. My app will use the Iranian bank system. I wish I could use Laravel Spark but its not suitable for my purpose.

Can you just suggest the proper setup for the database tables?

It depends on your needs, but here's an example (most of what I currently use):

• users
• subscriptions
• payments
• cards
• products
• vendors
• vendor_cards
• vendor_customers
• vendor_messages
• vendor_subscriptions

A user has a subscription. The subscription table includes information about the price and timing of payments, and whether it's active/cancelled/whatever. A subscription has payments, which also belong to the user. You might want to associate a subscription with a product, in case you want to sell multiple subscriptions/products/services.

The vendor_xxx stuff is there because it helps me separate vendor-specific logic from my core business logic. By "vendor" I mean things like Paypal, Stripe, etc. For example, a subscription has a vendor_subscription, which is where I store the vendor's subscription reference. Vendor_customer is where the vendor's customer reference is stored, if they give you one (and this belongs to a user). You might decide that some or all of this separation is unnecessary. It's up to you.

vendor_messages is there to log all the webhooks that I receive from (e.g.) Stripe. When a webhook comes in, I also convert it to a standard message format that makes sense to my domain, then process this message and update the DB (and other things like send emails).

I also have a SubscriptionPlan object, but this is a domain object rather than model/table. I'm using (e.g.) Stripe's subscription management, rather than scheduling the payments myself, so I also need plans defined in Stripe's system. This means I must connect my SubscriptionPlan with one of Stripe's subscription plans. For that, I give my plans a name, and I have an artisan command for updating Stripe (or Paypal, etc.) with my new plans (via their API).

@Mike Hopley Thanks a lot. It helped me much.

@alierfani Great, glad to help! =)

I should probably mention that the cards table only stores "safe" information about cards -- information that I get sent by Stripe.

So I'm only storing the last 4 digits, the expiry, and the type of card (e.g. "Visa").

If you do need to capture full card information, then you will need to comply with PCI regulations (which is not fun). Best avoided if you can.

2 years later can you share with us some thoughts about how to implement a subscription system? :)