database design for a payment system
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
add a comment |
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
add a comment |
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
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
logging database-design payment
edited Nov 14 '18 at 5:55
marc_s
579k12911181265
579k12911181265
asked Nov 14 '18 at 5:35
Kuldeep ThakurKuldeep Thakur
4517
4517
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 16 '18 at 6:05
Shishir SonekarShishir Sonekar
11518
11518
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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