Вы имеете дело с проблемой Supertype \ Subtype. Все платежи имеют что-то общее (по крайней мере ID и тип), но каждый тип имеет некоторые уникальные атрибуты. Вы можете моделировать этот сценарий несколькими способами, каждый из которых имеет плюсы и минусы.
«Классическое» решение - поставить супертип в один стол (оплата) и создать отдельную таблицу для каждого подтипа (способ оплаты). Существует соотношение 1: 1 между таблицей супертипа и каждой таблицей подтипа.
Пример, супертип стол:
Оплата (PaymentID, PaymentMethodID, дата, Идентификатор_пользователь ...)
подтипы:
CreditCardPayment (PaymentID, CardNumber, ....)
PayPalPayment (PaymentID, Секретный код, ...)
WireTransfer (PaymentID, AccountNumber, ...)
При создании платежа, вы создаете запись в оплате и запись в одном подтипов в одной транзакции. Этот способ реализации является хорошим, потому что он нормализуется, может быть легко расширен и защищен от ошибок. Но, к сожалению, это очень многословие и требует больше усилий, чем де-нормализованное решение.
Де-нормированное решение состоит в том, чтобы создать одну таблицу платежей и добавить кучу столбцов для всех способов оплаты. Когда вы создаете новый платеж, большинство столбцов имеют значения NULL, и только логика приложения знает, какие столбцы должны быть определены. Это решение намного проще в реализации, но имеет очевидные проблемы.
Есть больше вариантов для особых случаев, но я думаю, что они являются излишними для платежной системы. Так что это ваш звонок, что выбрать. Будучи человеком БД, я бы предпочел первый вариант.