Authorize.net ARB Вопросы
Я работаю над приложением, которое предоставляет 30-дневную пробную версию, а затем возможность ежемесячной или годовой подписки (по двум разным ценам).
Я использовал много информации, предоставленной Джоном Конде на его сайте (спасибо Джону), но хочу убедиться, что у меня есть правильное представление о том, как все это работает - я впервые делаю что-то с Authorize.net или подписками...
Поэтому, если у меня 30-дневная пробная версия, и кто-то решит, что он хочет заплатить сегодня, ему не следует выставлять счет в течение 60 дней. Я установил дату начала раньше, чем на 60 дней, но должен ли я увидеть какие-либо обвинения в Authorize.net, показывающие, что они ожидают?
Далее, это часть службы ARB, которая "следит" за обновлением, или я должен что-то сделать, чтобы регулярно проверять проверку. Я почти уверен, что это и есть ARB, и мне не нужно проверять cron каждый день, но я бы скорее задал тупой вопрос сейчас, а не кучу пропущенных обвинений позже.
Наконец, какую информацию вы бы порекомендовали мне хранить в моей локальной БД и что я должен позволить перехватить сервис ARB. В настоящее время я храню информацию о том, что представляет собой элемент подписки, кто является лицом, осуществляющим платеж (по идентификатору), имя на карте, последние четыре цифры карты, если они хотят указать, что было использовано, срок действия дата карты, так что я могу искать ожидающие истечения срока действия (если это не является частью ARB также) и дата начала подписки, заканчивается.
Любая дополнительная информация приветствуется.
2 ответа
Поэтому, если у меня 30-дневная пробная версия, и кто-то решит, что он хочет заплатить сегодня, ему не следует выставлять счет в течение 60 дней. Я установил дату начала раньше, чем на 60 дней, но должен ли я увидеть какие-либо обвинения в Authorize.net, показывающие, что они ожидают?
Используйте API-интерфейс AIM для начисления первоначального платежа, а затем установите дату начала в ARB равной 60 дням (когда производится их первый платеж). Вы не получите никакого уведомления о том, что подписка "ожидает рассмотрения", но если ARB API вернет вам идентификатор подписки, можно с уверенностью предположить, что первый платеж будет предпринят через 60 дней.
Далее, это часть службы ARB, которая "следит" за обновлением, или я должен что-то сделать, чтобы регулярно проверять проверку. Я почти уверен, что это и есть ARB, и мне не нужно проверять cron каждый день, но я бы скорее задал тупой вопрос сейчас, а не кучу пропущенных обвинений позже.
Вам не нужно ничего делать. "A" в ARB означает "Автоматизировано" и полностью автоматизировано. После того, как платеж запланирован, он будет выполняться автоматически до тех пор, пока не закончится подписка, вы не отмените подписку или срок ее действия не истечет, и вы не обновите ее до следующей запланированной даты выставления счета.
Наконец, какую информацию вы бы порекомендовали мне хранить в моей локальной БД и что я должен позволить перехватить сервис ARB. В настоящее время я храню информацию о том, что представляет собой элемент подписки, кто является лицом, осуществляющим платеж (по идентификатору), имя на карте, последние четыре цифры карты, если они хотят указать, что было использовано, срок действия дата карты, так что я могу искать ожидающие истечения срока действия (если это не является частью ARB также) и дата начала подписки, заканчивается.
Отправьте в ARB API столько информации, сколько сможете. Это значительно облегчает исследование транзакций в панели управления Authnet, поскольку вы можете сравнить то, что вы захватили, с тем, что они показывают в своей истории транзакций.
Похоже, вы храните информацию, которая будет полезна для вас. Я бы зашифровал все, что связано с кредитной картой, чтобы сделать его менее полезным, если ваша БД взломана. Вы храните достаточно информации, чтобы хакер мог использовать ее, чтобы убедить своих клиентов в том, что у них есть номер их кредитной карты, и тогда все становится действительно ужасным.
Ну, в общем, вам следует избегать хранения информации CC (по соображениям безопасности), поэтому лучше хранить все в ARB.
Вы должны планировать платежи правильно, когда пользователь регистрируется, и установить startDate в SOAP-вызове на 60 дней спустя. Сохраняйте ключ транзакции или как бы он ни звонил, чтобы в любое время отменить подписку на ARB. Если вы делаете это таким образом, вы можете вообще избежать обработки платежей, и вам просто нужно обрабатывать подписку и отписку.