Пользовательский платежный метод

[NikaS]

Поделитесь пожалуйста опытом

Делаю свой платежный метод для оплаты юридическим лицом Magento 1*. В форме на фронте есть восемь полей для заполнения покупателем

1) Название организации
2) ИНН
3) КПП
4) ОГРН
5) ОКПО
6) БИК
7) Расчетный счет
8) Юр.Адрес

Все это я уже реализовала, проблема заключается выборе хранения этих данных. В интернете в примерах создания платежных методов рекомендуют использовать две таблицы

ALTER TABLE `{$installer->getTable('sales/quote_payment')}`
и
ALTER TABLE `{$installer->getTable('sales/order_payment')}`

Как раз вот тут меня и терзают сомнения, приведенные таблицы и так не самые "худые" и если я туда добавлю еще восемь полей не будет ли проблем?

Если я пойду другим путем и создам свою таблицу под данный платежный метод какие подводные камни меня могут ждать?

[Anonymous]

Ну первое что приходит на ум при хранении данных в отдельной таблице, это дополнительные JOIN которые придется конструировать для выборки и отображения из них данных. Вопрос только в том, зачем адресные данные плательщика или получателя хранить вместе с данными о платеже?

[NikaS]

Спасибо что откликнулись. Юр.Адрес в нашем случае не стоит воспринимать как адрес, его нужно воспринимать как обязательный реквизит для выставления счета на оплату, аналогичный ИНН или ОГРН. Дело в том что адрес доставки с юридическим адресом совпадают очень редко. В движке уже есть поля для ввода двух разных адресов и покупатели вводит какие угодно адреса, но только не юридический, проверенно временем. Бухгалтерию это сильно нервирует, постоянно приходится редактировать вручную
Разбирая работу одного стороннего модуля наткнулась на то что он не создавал под себя поля в базе, а использует уже имеющиеся поля модулей оплаты которые есть "из коробки". Как вы смотрите на такой вариант и что может быть нехорошего?

[Anonymous]

У работы платежных модулей в Мадженто есть определенный алгоритм при котором отображается просто выбор того или иного метода. Вставлять туда форму ввода данных в принципе можно, но в интерфейсе это будет выглядеть не очень.

Другой важный момент, отображение этих данных для работы. Нужно либо делать выгрузку этих данных для обработки во внешнюю систему, либо допиливать интерфейс админки так, чтобы эти данные отображались. К тому же помимо простого отображения в админке есть возможность создания или редактирования заказов, и там тоже есть определенный алгоритм работы в том числе с платежными данными.

То есть сделать конечно можно, но трудозатраты будут большие. Такое за пару дней не написать. Так что возможно есть другие варианты решения проблемы? Какие-то органзационные например, которые дешевле обойдутся.

[Anonymous]

Хотя если говорить просто о размерах таблиц, то максимальный размер данных в одной строке, которые допускает MySQL это 65Кбайт, а это 255 полей длинной по 255 символов каждый. Такой размер перебрать сложно :-).