Какова стратегия синхронизации с плейд-транзакциями?

Мне нужно синхронизировать транзакции по счетам для набора элементов. Для меня это означает: 1. Сделайте первоначальную загрузку всех исторических транзакций. 2. Получайте новые транзакции, когда они доступны. 3. Убедитесь, что ни одна транзакция не упала на пол.

Из документации и API неясно, как это можно сделать надежно.

API создания имеет параметр веб-перехватчика, поэтому, похоже, мне следует сразу же настроить веб-перехватчик при получении транзакций. Если я не пропустил все транзакции навсегда?

Могу ли я тянуть все транзакции только через API? Я заметил, что параметры имеют смещение. Это для курсора? Могу ли я запросить транзакции прошлого и прошлого, чтобы вызвать повторную загрузку транзакций?

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

И я помню, как читал где-то в документе, что идентификаторы учетных записей и идентификаторы транзакций связаны с ACCESS_TOKEN. Означает ли это, что идентификаторы учетных записей и идентификаторы транзакций нельзя использовать для уникальной идентификации данных в токенах?


webhooks plaid
person Todd Hoff    schedule 15.07.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Plaid заявляет, что они могут получать данные о транзакциях за последние два года. Однако количество исторических транзакций, предоставленных банками, варьируется от банка к банку. Я видел, как некоторые банки предоставляют данные за последние три месяца, тогда как некоторые возвращают данные за последние два года. Я также видел, что некоторые банки не поддерживают возврат каких-либо данных о транзакциях.

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

Plaid возвращает только 500 транзакций за вызов (я думаю). Таким образом, вы отвечаете за разбиение на страницы при извлечении исторических данных.

Вы всегда можете получить исторические данные, но вы сможете получить максимум только за последние два года. Каждый прошедший день вы не сможете получить данные за первый день два года назад. Это движущееся окно. Обычно я кеширую данные на нашей стороне, так как вы не сможете получить доступ к данным старше двух лет.

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

Надеюсь, это поможет.

person Nick    schedule 16.07.2018
comment
Когда вы говорите кэшированные данные, вы имеете в виду их размещение в базе данных? - person Mark McKelvy; 03.08.2018
comment
@MarkMcKelvy - Да, я это и имел в виду. Спасибо за уточнение. Я использовал комбинацию Mongo, S3 и ElasticSearch. Mongo для хранения записей для повседневных вещей. S3 для полной резервной копии. И ElasticSearch для аналитики. - person Nick; 03.08.2018