Developers May 13, 2020

What to store from Stripe transaction?

Masatoshi Nishimura @massanishi

Stripe is the number one choice for the Indiehackers (Indiehackers is Stripe family!). A lot of you have experience dealing with their payment services.

I'm now looking into the documentation to implement subscription membership for my Chrome Extension. I just know that you won't be storing credit card info. But is there a best practice what to store in your own database? Do you store everything returned by Stripe in something like json format?

  1. 3

    You can get all the information about the transaction by calling stripe, later when you need it. So save what you need to display on a payments page. For one-off receipts you can always make that call.

    Store customer reference id. If you have products and skus you should store those names and IDs.

    1. 1

      I also just store the customer id (from stripe) attached to the user in my database. Other than that I have a field for their paid status (that gets set on a subscription event (one through my api, the other more unfortunate via webhook listening to a stripe event that cancels the subscription)).

    2. 1

      Oh nice! It's a relief to know you can always retrieve back any info. Dummy proof.

      I see all types of ids: session id, customer id, invoice prefix, etc. Do you display the customer id at the payment successful page at the end?

      1. 2
        1. Use the webhook from Stripe to save this information.

        2. Here's some potential fields you could save. They will be somewhat different between subscriptions and product checkouts.

        product_id,
        product_price,
        sku_id,
        sku_name,
        stripe_payment_id,
        stripe_customer_id,
        stripe_customer_email,
        stripe_client_reference_id,
        amount,
        currency
        
        1. I don't display the customer ID. I do display to the customer the email they used.
        1. 1

          Hands on entry names! Helps me think much better! I like you attached the customer email along with the subscription info. Ya it is a good idea to display email at the checkout. I'll steal it, thanks:)

  2. 2

    In my experience of building integrations with Stripe, I would say you should create a model where you destructure the data you care about (it might be the stripe_id, amount, etc.) and a json field for the raw data.

    In the future, you might realise you need more data, and it would be easy to cycle through the raw json fields extracting what you need.

    When it comes to dealing with money, I follow a simple principle: always record everything.

    Hope this helps

    1. 1

      I see! My challenge has been I'm not sure what data I should be caring for. Too newbie. Storing more than needed right now is a good principle!

  3. 2

    Not super familiar with Chrome Extensions, but it depends what information you care about quickly. For sure save customer_id and maybe plan_id, then you can use those to make API calls to get more info.

    Personally, I also have trial_ends_at & ends_at to check if they still have an active subscription, and card_brand, card_last_fourto display on their billing page.

    Hope this helps. It really depends on what information you want to make an API call for and which you want locally.

    1. 1

      Thanks Michael! Storing trial period might be a good idea. Seems like I should start from listing out which potential API calls to make.. Did you store all those info in one table like "payment" for example?

      1. 2

        I mainly write my projects using Laravel and the laravel/cashier package which sets up all the defaults.

        So I have the customer ID, card brand, last 4, and trial end date on the users table.

        And then a subscriptions table with:

        • user_id reference to the Users,
        • name local name for the subscription
        • stripe_id Stripe's subscription ID
        • stripe_plan Stripe's plan ID
        • quantity For billing quantity ( I never use this, but it's part of the package)
        • status Quick string like (active, canceled, past_due)
        • trial_ends_at, ends_at, created_at, updated_at
        1. 2

          Oh thanks! Going through the third party doc is always initially overwhelming. Your info really helps, the real world example:)

Recommended Posts