database design for a payment system










0















I have four table as below:



FEES



fees_id, interest, amount, total_amount, status_id, is_recurring recurring_status from_date to_date payment_id
F001 1.50 1000 1015 1 N NULL 2018-11-01 2018-11-01 1
F002 2.00 2000 1020 1 Y COMPLETE 2018-11-01 2018-11-20 2


PAYMENT



id, amount, payment_date, txn_id, bnk_name, txn_status, pay_mode, dd_no, dd_date, chk_no, chk_date
1 1015 2018-11-11 TXN0001 SBI 1 1 NULL NULL NULL NULL
2 1020 2018-11-20 NULL NULL NULL 3 DNO001 2018-11-19 NULL NULL


PAY_MODES



id name display
------------------
1 ONLINE Y
2 CASH Y
3 DRAFT Y
4 CHECK Y


PAYMENT_STATUS



id status display
-------------------
1 PAID Y
2 UNPAID Y


A fee can be paid by any of the four pay modes.



I have few questions:



  • Is it ok (in this scenario) to have one payment table for all pay modes OR is there any better option?

  • A fee can be recurring (paid every month until its recurring status is completed). How can I handle these payments?

  • Do I need to store each payment response (in case of online payment) whether success, fail or whatever. If yes, should I use a separate table or store in a file?









share|improve this question




























    0















    I have four table as below:



    FEES



    fees_id, interest, amount, total_amount, status_id, is_recurring recurring_status from_date to_date payment_id
    F001 1.50 1000 1015 1 N NULL 2018-11-01 2018-11-01 1
    F002 2.00 2000 1020 1 Y COMPLETE 2018-11-01 2018-11-20 2


    PAYMENT



    id, amount, payment_date, txn_id, bnk_name, txn_status, pay_mode, dd_no, dd_date, chk_no, chk_date
    1 1015 2018-11-11 TXN0001 SBI 1 1 NULL NULL NULL NULL
    2 1020 2018-11-20 NULL NULL NULL 3 DNO001 2018-11-19 NULL NULL


    PAY_MODES



    id name display
    ------------------
    1 ONLINE Y
    2 CASH Y
    3 DRAFT Y
    4 CHECK Y


    PAYMENT_STATUS



    id status display
    -------------------
    1 PAID Y
    2 UNPAID Y


    A fee can be paid by any of the four pay modes.



    I have few questions:



    • Is it ok (in this scenario) to have one payment table for all pay modes OR is there any better option?

    • A fee can be recurring (paid every month until its recurring status is completed). How can I handle these payments?

    • Do I need to store each payment response (in case of online payment) whether success, fail or whatever. If yes, should I use a separate table or store in a file?









    share|improve this question


























      0












      0








      0








      I have four table as below:



      FEES



      fees_id, interest, amount, total_amount, status_id, is_recurring recurring_status from_date to_date payment_id
      F001 1.50 1000 1015 1 N NULL 2018-11-01 2018-11-01 1
      F002 2.00 2000 1020 1 Y COMPLETE 2018-11-01 2018-11-20 2


      PAYMENT



      id, amount, payment_date, txn_id, bnk_name, txn_status, pay_mode, dd_no, dd_date, chk_no, chk_date
      1 1015 2018-11-11 TXN0001 SBI 1 1 NULL NULL NULL NULL
      2 1020 2018-11-20 NULL NULL NULL 3 DNO001 2018-11-19 NULL NULL


      PAY_MODES



      id name display
      ------------------
      1 ONLINE Y
      2 CASH Y
      3 DRAFT Y
      4 CHECK Y


      PAYMENT_STATUS



      id status display
      -------------------
      1 PAID Y
      2 UNPAID Y


      A fee can be paid by any of the four pay modes.



      I have few questions:



      • Is it ok (in this scenario) to have one payment table for all pay modes OR is there any better option?

      • A fee can be recurring (paid every month until its recurring status is completed). How can I handle these payments?

      • Do I need to store each payment response (in case of online payment) whether success, fail or whatever. If yes, should I use a separate table or store in a file?









      share|improve this question
















      I have four table as below:



      FEES



      fees_id, interest, amount, total_amount, status_id, is_recurring recurring_status from_date to_date payment_id
      F001 1.50 1000 1015 1 N NULL 2018-11-01 2018-11-01 1
      F002 2.00 2000 1020 1 Y COMPLETE 2018-11-01 2018-11-20 2


      PAYMENT



      id, amount, payment_date, txn_id, bnk_name, txn_status, pay_mode, dd_no, dd_date, chk_no, chk_date
      1 1015 2018-11-11 TXN0001 SBI 1 1 NULL NULL NULL NULL
      2 1020 2018-11-20 NULL NULL NULL 3 DNO001 2018-11-19 NULL NULL


      PAY_MODES



      id name display
      ------------------
      1 ONLINE Y
      2 CASH Y
      3 DRAFT Y
      4 CHECK Y


      PAYMENT_STATUS



      id status display
      -------------------
      1 PAID Y
      2 UNPAID Y


      A fee can be paid by any of the four pay modes.



      I have few questions:



      • Is it ok (in this scenario) to have one payment table for all pay modes OR is there any better option?

      • A fee can be recurring (paid every month until its recurring status is completed). How can I handle these payments?

      • Do I need to store each payment response (in case of online payment) whether success, fail or whatever. If yes, should I use a separate table or store in a file?






      logging database-design payment






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 14 '18 at 5:55









      marc_s

      579k12911181265




      579k12911181265










      asked Nov 14 '18 at 5:35









      Kuldeep ThakurKuldeep Thakur

      4517




      4517






















          1 Answer
          1






          active

          oldest

          votes


















          1














          Que: Is it ok (in this scenario) to have one payment table for all pay modes OR is there any better option?




          Yes, all the payment should be in one Payment Table. This helps to
          maintain the transactional integrity constraint. Also, it will helpful
          for you in future while generating various reports




          Que: A fee can be recurring (paid every month until its recurring status is completed). How can I handle these payments?




          You should have another table for maintaining the recurring payments
          record as Subscription table and at every recurring payment event of a
          record insert new entry into payment table. So, One subscription
          record will be related to multiple payment entries.




          Que: Do I need to store each payment response (in case of online payment) whether success, fail or whatever. If yes, should I use a separate table or store in a file?




          Yes, you should store the payment response in the same payment table
          record. This will help you out in the failover detection as well as
          major help in Audit Log.







          share|improve this answer






















            Your Answer






            StackExchange.ifUsing("editor", function ()
            StackExchange.using("externalEditor", function ()
            StackExchange.using("snippets", function ()
            StackExchange.snippets.init();
            );
            );
            , "code-snippets");

            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "1"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53293775%2fdatabase-design-for-a-payment-system%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            1














            Que: Is it ok (in this scenario) to have one payment table for all pay modes OR is there any better option?




            Yes, all the payment should be in one Payment Table. This helps to
            maintain the transactional integrity constraint. Also, it will helpful
            for you in future while generating various reports




            Que: A fee can be recurring (paid every month until its recurring status is completed). How can I handle these payments?




            You should have another table for maintaining the recurring payments
            record as Subscription table and at every recurring payment event of a
            record insert new entry into payment table. So, One subscription
            record will be related to multiple payment entries.




            Que: Do I need to store each payment response (in case of online payment) whether success, fail or whatever. If yes, should I use a separate table or store in a file?




            Yes, you should store the payment response in the same payment table
            record. This will help you out in the failover detection as well as
            major help in Audit Log.







            share|improve this answer



























              1














              Que: Is it ok (in this scenario) to have one payment table for all pay modes OR is there any better option?




              Yes, all the payment should be in one Payment Table. This helps to
              maintain the transactional integrity constraint. Also, it will helpful
              for you in future while generating various reports




              Que: A fee can be recurring (paid every month until its recurring status is completed). How can I handle these payments?




              You should have another table for maintaining the recurring payments
              record as Subscription table and at every recurring payment event of a
              record insert new entry into payment table. So, One subscription
              record will be related to multiple payment entries.




              Que: Do I need to store each payment response (in case of online payment) whether success, fail or whatever. If yes, should I use a separate table or store in a file?




              Yes, you should store the payment response in the same payment table
              record. This will help you out in the failover detection as well as
              major help in Audit Log.







              share|improve this answer

























                1












                1








                1







                Que: Is it ok (in this scenario) to have one payment table for all pay modes OR is there any better option?




                Yes, all the payment should be in one Payment Table. This helps to
                maintain the transactional integrity constraint. Also, it will helpful
                for you in future while generating various reports




                Que: A fee can be recurring (paid every month until its recurring status is completed). How can I handle these payments?




                You should have another table for maintaining the recurring payments
                record as Subscription table and at every recurring payment event of a
                record insert new entry into payment table. So, One subscription
                record will be related to multiple payment entries.




                Que: Do I need to store each payment response (in case of online payment) whether success, fail or whatever. If yes, should I use a separate table or store in a file?




                Yes, you should store the payment response in the same payment table
                record. This will help you out in the failover detection as well as
                major help in Audit Log.







                share|improve this answer













                Que: Is it ok (in this scenario) to have one payment table for all pay modes OR is there any better option?




                Yes, all the payment should be in one Payment Table. This helps to
                maintain the transactional integrity constraint. Also, it will helpful
                for you in future while generating various reports




                Que: A fee can be recurring (paid every month until its recurring status is completed). How can I handle these payments?




                You should have another table for maintaining the recurring payments
                record as Subscription table and at every recurring payment event of a
                record insert new entry into payment table. So, One subscription
                record will be related to multiple payment entries.




                Que: Do I need to store each payment response (in case of online payment) whether success, fail or whatever. If yes, should I use a separate table or store in a file?




                Yes, you should store the payment response in the same payment table
                record. This will help you out in the failover detection as well as
                major help in Audit Log.








                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 16 '18 at 6:05









                Shishir SonekarShishir Sonekar

                11518




                11518





























                    draft saved

                    draft discarded
















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53293775%2fdatabase-design-for-a-payment-system%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Use pre created SQLite database for Android project in kotlin

                    Darth Vader #20

                    Ondo