Acquirer id что это
acquirer reference number
Смотреть что такое «acquirer reference number» в других словарях:
ISO 8583 — ISO 8583 стандарт ISO, описывающий процесс передачи и формат финансовых сообщений (транзакций) систем, обрабатывающих данные банковских платёжных карт. Содержание 1 Введение 2 Индикатор типа сообщения 2.1 … Википедия
ISO 8583 — Standard para Transacciones Financieras con Mensajes originados en una tarjeta Especificaciones de los mensajes de intercambio es el standard de la International Organization for Standardization para sistemas que intercambian transacciones… … Wikipedia Español
Credit card — Personal finance Credit and debt Pawnbroker Student loan Employment contract Salary Wage Empl … Wikipedia
Automated Teller Machine Communication Security — Automated Teller Machines were first used in 1939. Nowadays, about 1.5 million are installed worldwide [ [http://www.atmmarketplace.com/news story 24706.htm Number of ATMs worldwide expected to hit 1.5 million in December 2005] www.atmmarketplace … Wikipedia
Electronic funds transfer — or EFT refers to the computer based systems used to perform financial transactions electronically.The term is used for a number of different concepts: * Cardholder initiated transactions, where a cardholder makes use of a payment card * Direct… … Wikipedia
Roman Law — Roman Law † Catholic Encyclopedia ► Roman Law In the following article this subject is briefly treated under the two heads of; I. Principles; II. History. Of these two divisions, I is subdivided into: A. Persons; B. Things; C. Actions … Catholic encyclopedia
American Express — Company Type Public Traded as NYSE: AXP Dow Jones Component … Wikipedia
Royalties — Not to be confused with Royal family. Royalty cheque. Royalties (sometimes, running royalties, or private sector taxes) are usage based payments made by one party (the licensee ) to another (the licensor ) for the right to ongoing use of an asset … Wikipedia
Supernatural (TV series) — This article is about the U.S. TV series. For the UK TV drama of the same name, see Supernatural (1977 TV series). For the UK nature show of the same name, see Supernatural: Unseen Power of Animals. Supernatural The opening title for season 7 … Wikipedia
Pac-Man — This article is about the original Pac Man arcade game from 1980. For other uses, see Pac Man (disambiguation). Pac Man No … Wikipedia
Computers and Information Systems — ▪ 2009 Introduction Smartphone: The New Computer. The market for the smartphone in reality a handheld computer for Web browsing, e mail, music, and video that was integrated with a cellular telephone continued to grow in 2008. According to… … Universalium
Мониторинг авторизационных запросов по банковским картам: эмиссия
Полная версия статьи размещена в печатной версии журнала
Цели и методы
1) привлечь внимание к картам/терминалам с аномальной (повышенной) активностью;
2) своевременно обнаружить и выявить подозрительные и мошеннические операции;
3) минимизировать сумму потенциальных (последующих возможных) потерь.
Разумная, логически обоснованная интерпретация событий, связанных во времени, с учетом значений параметров, хранящихся в авторизационных сообщениях, позволяет достаточно обоснованно предположить характер поведения лица, использующего карту. Сочетание явно противоречащих или, наоборот, характерно сопутствующих друг другу обстоятельств является достаточным основанием для проведения расследования и принятия иных адекватных мер (включая немедленное изменение статуса карты, срочное информирование/уведомление держателя и пр.), направленных на снижение возможных рисков и потенциальных убытков как банка, так и клиента.
Решения банков по мониторингу можно классифицировать исходя из того, являются они заказными (разработанными сторонними фирмами) или самописными.
Существует и такая классификация решений по мониторингу:
— основанные на правилах;
— системы искусственного интеллекта;
1) много справочной литературы;
2) хорошая поддержка, много комментариев в сети Интернет;
3) не требуется глубокого знания SQL;
4) можно освоить и начать эффективно использовать в очень короткие сроки;
5) понятный дружественный интерфейс;
6) можно использовать самые разнообразные шрифты для генерации отчетов, в том числе разные шрифты и цвета для разных полей отчетов и форм;
Следует особо отметить, что в ходе проверок (on-site review) инспекторы МПС Visa уделяют повышенное внимание именно аспектам соответствия банков требованиям в части мониторинга. Несоблюдение этих требований приводит к довольно тяжким последствиям вплоть до наложения штрафов.
Основные термины и определения
1) маршрутизация информационных сообщений по картам/в устройствах банка;
2) обслуживание авторизационных запросов по картам/в устройствах банка;
3) предоставление расчетной информации (клиринг) по картам и операциям в устройствах банка.
Методы реализации
В статье акцент будет сделан на реализации системы мониторинга в среде MS Access как наиболее доступной и легкой в использовании.
Совершенно очевидно, что доступ к таблицам Oracle должен быть ограничен режимом «только чтение» во избежание случайного повреждения данных. Хорошей идеей является использование отдельного сервера, хранящего полные копии производственных баз данных Oracle, что легко реализуется на обычном, не серверном, «железе», например под управлением OS Linux и MySQL Server. В задачи системных администраторов будет входить только решение вопроса своевременного ежесуточного копирования необходимых полей таблиц Oracle с производственных серверов на выделенный сервер мониторинга.
Такая схема позволяет за умеренную цену (фактически учитывается только стоимость аппаратного обеспечения платформы) решить сразу несколько задач:
— доступ только к необходимым полям таблиц Oracle;
— гарантия сохранности производственных таблиц Oracle и их данных;
— возможность предоставить доступ к данным только тем пользователям, кому это действительно необходимо.
Реализация накопления данных БД-мониторинга на выделенном сервере под управлением MySQL (или иного другого поставщика ПО, например Oracle, PostGres или MS SQL Server) имеет еще одно важное преимущество: данные можно накапливать практически бесконечно (размер БД-мониторинга будет зависеть только от емкости физического жесткого диска). При импорте данных в таблицы MS Access следует принимать в расчет, что размер файла с данными в этих БД не может превышать 2 Гб.
Для работы и построения СУБД-мониторинга авторизационных запросов по эмиссии, как правило, необходимо иметь доступ к нижеследующим полям авторизационного запроса:
9) идентификатор банка-эквайера (Acquirer ID);
11) номер терминала;
14) сумма и валюта запроса в местной валюте;
15) сумма и валюта запроса в валюте счета;
16) сумма и валюта запроса в единой валюте (вычисляемое значение, см. ниже);
17) Response Code (RC);
18) код авторизации (если был выдан);
19) признак отмены (Reversal);
21) прочие поля, в зависимости от фронтального СПО.
Имея такой инструмент, можно очень легко сравнивать все авторизуемые суммы по одной шкале (в одной валюте), чтобы ошибочно не складывать рубли с тенге, динары с песо, доллары с евро и пр., например при анализе оборотов, построении трендов, вычислении средних значений, генерации любых отчетов и т.д.
Мониторинг авторизационных запросов (эмиссия)
1. Общее количество запросов по карте.
2. Общее количество запросов по карте с разбивкой по МСС высокого риска.
3. Общее количество запросов по карте в одном и том же терминале (ТСП).
4. Общее количество запросов по карте с разбивкой по странам высокого риска.
5. Общее количество попыток ввода неверного пин по карте.
6. Общее количество авторизационных запросов по карте с POS Entry Mode, PEM = ‘02’ (совет: анализировать PEM, отличный от ‘90’).
7. Общая сумма запросов по карте.
8. Общая сумма запросов по карте с разбивкой по МСС высокого риска.
9. Общая сумма запросов по карте с разбивкой по странам высокого риска.
10. Сумма отдельного запроса по карте превышает заданное наперед значение в единой валюте.
11. Сумма отдельного запроса по карте превышает заданное наперед значение с разбивкой по МСС высокого риска.
12. Сумма отдельного запроса по карте превышает заданное наперед значение с разбивкой по странам высокого риска.
13. Анализ cross-border авторизаций по карте (запросы из разных стран в течение некоего наперед заданного промежутка времени, например в одни сутки).
14. Анализ авторизационных запросов по карте в режиме ручного ввода номера карты (key entry mode).
15. Анализ запросов по картам с высоким объемом авторизационных запросов, предваряющихся отказами (в процентном отношении к наперед заданным значениям).
16. Анализ процентного отношения фактически потраченных средств в розничной сети и полученных наличными (сравнение поведения клиента с имеющимся шаблоном).
Легко заметить, что запросы делятся на группы, а именно:
1) общее количество (6 запросов);
2) общая сумма (3 запроса);
3) сумма отдельного запроса (в единой валюте, 3 запроса);
4) сравнительный анализ (4 запроса).
Ниже рассмотрим подробно все 16 обязательных SQL-запросов, которые эмитенты должны ежедневно исполнять и анализировать.
Таким образом, в результате работы каждого из 16 SQL-запросов («выборка») на выходе получаем таблицу из двух столбцов:
1. Общее количество запросов по карте.
В этом SQL-запросе для каждой карты анализируется только общее число (количество) любых (успешных и неуспешных) авторизационных запросов за некоторую дату (как правило, предыдущий рабочий день, в понедельник — за пятницу, субботу и воскресенье, т.е. за все предыдущие рабочие дни).
Это очень простой запрос SQL, в нем для каждой карты нужно вычислить всего лишь общее число событий (авторизационных запросов, имевших место за анализируемый период (календарную дату)).
Например, у нас в портфеле банка 10 карт. Номера карт в примере соответственно от 0 до 9. Если по всем картам за определенную дату (день, предшествующий дате исполнения запроса) не было событий (авторизационных запросов), а по картам 2, 5 и 9 были соответственно 5, 2 и 6 запросов, на выходе в результате работы SQL-запроса (1 — Общее количество запросов по карте) будем иметь следующий результат:
Видно, что наибольшее число баллов (60) набрала карта № 9, так как именно по этой карте зафиксировано наибольшее число событий (авторизационных запросов, любых, не обязательно успешных в контексте данного запроса), что потенциально несет в себе больший риск (возможных финансовых потерь клиента или банка, если клиент — мошенник), чем по картам, не имевшим запросов или имевшим меньшее их число. Данное утверждение относится именно только к числу запросов, а не к общей их сумме или прочим аспектам (МСС, страна и пр.).
2. Общее количество запросов по карте с разбивкой по МСС высокого риска.
Существует устойчивое понятие «МСС повышенного риска» (МСС — merchant category code). К ним традиционно относят такие коды, как 5944, 7995, в последнее время — 6012, 8999 и пр. (на выбор разработчика БД-мониторинга). Официально МПС рассылают участникам ежеквартальные бюллетени, содержащие в том числе и списки МСС повышенного риска. Аналогично предыдущему SQL-запросу в данном анализируется количество событий, МСС которых совпадает с кодами повышенного риска. Точно так же следует начислять «штрафные» баллы по схеме, полностью совпадающей с изложенной выше, — чем больше запросов, тем больше баллов (можно составить таблицу значений начисляемых баллов даже для каждого МСС).
Это чуть более сложный SQL-запрос, в нем нужно анализировать и учитывать число запросов, исходивших из ТСП с определенным МСС, и в случае совпадения значений МСС, считающихся высокорисковыми, начислять соответствующее заданное в таблице МСС количество баллов.
Разработчикам СУБД следует иметь таблицу МСС с эмпирически заданными наперед значениями «штрафных» баллов, например для каждого запроса (успешного/неуспешного) из ТСП с МСС 5944 начислять карте 20 баллов, при запросе из ТСП с МСС 7995 — 100 баллов и т.д.
3. Общее количество запросов по карте в одном и том же терминале (ТСП).
В этом SQL-запросе анализируется количество запросов по карте, сделанных из одного и того же терминала (поле Terminal ID). Чем больше запросов, тем больше число баллов (подозрительно, когда одна и та же карта «гуляет» в одном и том же терминале, очень похоже на «прозвон» доступного остатка или потенциальное мошенничество). Обычно по одной и той же карте совершается 1–2 операции в одном терминале в день, как то предписано в Правилах и Требованиях МПС (оформить все покупки одной транзакцией). Для более жесткого соблюдения условий уникальности терминала можно анализировать еще и поле Acquirer ID, что гарантирует факт соблюдения формального требования МПС (предполагается, что у одного и того же эквайера не может быть терминалов с одинаковыми номерами).
Мониторинг авторизационных запросов по банковским картам: эмиссия
В статье проведен подробный анализ шестнадцати SQL-запросов, которые эмитенты обязаны выполнять ежедневно при мониторинге авторизационных запросов по операциям с банковскими картами. Приведены практические советы и примеры из передового опыта реализации баз данных мониторинга с использованием методов и средств MS Access. Многие SQL-запросы проиллюстрированы вариантами табличных значений, которые предполагается получать на выходе.
Цели и методы
1) привлечь внимание к картам/терминалам с аномальной (повышенной) активностью;
2) своевременно обнаружить и выявить подозрительные и мошеннические операции;
3) минимизировать сумму потенциальных (последующих возможных) потерь.
Разумная, логически обоснованная интерпретация событий, связанных во времени, с учетом значений параметров, хранящихся в авторизационных сообщениях, позволяет достаточно обоснованно предположить характер поведения лица, использующего карту. Сочетание явно противоречащих или, наоборот, характерно сопутствующих друг другу обстоятельств является достаточным основанием для проведения расследования и принятия иных адекватных мер (включая немедленное изменение статуса карты, срочное информирование/уведомление держателя и пр.), направленных на снижение возможных рисков и потенциальных убытков как банка, так и клиента.
Решения банков по мониторингу можно классифицировать исходя из того, являются они заказными (разработанными сторонними фирмами) или самописными.
Существует и такая классификация решений по мониторингу:
— основанные на правилах;
— системы искусственного интеллекта;
1) много справочной литературы;
2) хорошая поддержка, много комментариев в сети Интернет;
3) не требуется глубокого знания SQL;
4) можно освоить и начать эффективно использовать в очень короткие сроки;
5) понятный дружественный интерфейс;
6) можно использовать самые разнообразные шрифты для генерации отчетов, в том числе разные шрифты и цвета для разных полей отчетов и форм;
Следует особо отметить, что в ходе проверок (on-site review) инспекторы МПС Visa уделяют повышенное внимание именно аспектам соответствия банков требованиям в части мониторинга. Несоблюдение этих требований приводит к довольно тяжким последствиям вплоть до наложения штрафов.
Основные термины и определения
1) маршрутизация информационных сообщений по картам/в устройствах банка;
2) обслуживание авторизационных запросов по картам/в устройствах банка;
3) предоставление расчетной информации (клиринг) по картам и операциям в устройствах банка.
Методы реализации
В статье акцент будет сделан на реализации системы мониторинга в среде MS Access как наиболее доступной и легкой в использовании.
Совершенно очевидно, что доступ к таблицам Oracle должен быть ограничен режимом «только чтение» во избежание случайного повреждения данных. Хорошей идеей является использование отдельного сервера, хранящего полные копии производственных баз данных Oracle, что легко реализуется на обычном, не серверном, «железе», например под управлением OS Linux и MySQL Server. В задачи системных администраторов будет входить только решение вопроса своевременного ежесуточного копирования необходимых полей таблиц Oracle с производственных серверов на выделенный сервер мониторинга.
Такая схема позволяет за умеренную цену (фактически учитывается только стоимость аппаратного обеспечения платформы) решить сразу несколько задач:
— доступ только к необходимым полям таблиц Oracle;
— гарантия сохранности производственных таблиц Oracle и их данных;
— возможность предоставить доступ к данным только тем пользователям, кому это действительно необходимо.
Реализация накопления данных БД-мониторинга на выделенном сервере под управлением MySQL (или иного другого поставщика ПО, например Oracle, PostGres или MS SQL Server) имеет еще одно важное преимущество: данные можно накапливать практически бесконечно (размер БД-мониторинга будет зависеть только от емкости физического жесткого диска). При импорте данных в таблицы MS Access следует принимать в расчет, что размер файла с данными в этих БД не может превышать 2 Гб.
Для работы и построения СУБД-мониторинга авторизационных запросов по эмиссии, как правило, необходимо иметь доступ к нижеследующим полям авторизационного запроса:
9) идентификатор банка-эвайера (Acquirer ID);
11) номер терминала;
14) сумма и валюта запроса в местной валюте;
15) сумма и валюта запроса в валюте счета;
16) сумма и валюта запроса в единой валюте (вычисляемое значение, см. ниже);
17) Response Code (RC);
18) код авторизации (если был выдан);
19) признак отмены (Reversal);
21) прочие поля, в зависимости от фронтального СПО.
Имея такой инструмент, можно очень легко сравнивать все авторизуемые суммы по одной шкале (в одной валюте), чтобы ошибочно не складывать рубли с тенге, динары с песо, доллары с евро и пр., например при анализе оборотов, построении трендов, вычислении средних значений, генерации любых отчетов и т.д.
Мониторинг авторизационных запросов (эмиссия)
1. Общее количество запросов по карте.
2. Общее количество запросов по карте с разбивкой по МСС высокого риска.
3. Общее количество запросов по карте в одном и том же терминале (ТСП).
4. Общее количество запросов по карте с разбивкой по странам высокого риска.
5. Общее количество попыток ввода неверного пин по карте.
6. Общее количество авторизационных запросов по карте с POS Entry Mode, PEM = ‘02’ (совет: анализировать PEM, отличный от ‘90’).
7. Общая сумма запросов по карте.
8. Общая сумма запросов по карте с разбивкой по МСС высокого риска.
9. Общая сумма запросов по карте с разбивкой по странам высокого риска.
10. Сумма отдельного запроса по карте превышает заданное наперед значение в единой валюте.
11. Сумма отдельного запроса по карте превышает заданное наперед значение с разбивкой по МСС высокого риска.
12. Сумма отдельного запроса по карте превышает заданное наперед значение с разбивкой по странам высокого риска.
13. Анализ cross-border авторизаций по карте (запросы из разных стран в течение некоего наперед заданного промежутка времени, например в одни сутки).
14. Анализ авторизационных запросов по карте в режиме ручного ввода номера карты (key entry mode).
15. Анализ запросов по картам с высоким объемом авторизационных запросов, предваряющихся отказами (в процентном отношении к наперед заданным значениям).
16. Анализ процентного отношения фактически потраченных средств в розничной сети и полученных наличными (сравнение поведения клиента с имеющимся шаблоном).
Легко заметить, что запросы делятся на группы, а именно:
1) общее количество (6 запросов);
2) общая сумма (3 запроса);
3) сумма отдельного запроса (в единой валюте, 3 запроса);
4) сравнительный анализ (4 запроса).
Ниже рассмотрим подробно все 16 обязательных SQL-запросов, которые эмитенты должны ежедневно исполнять и анализировать.
Таким образом, в результате работы каждого из 16 SQL-запросов («выборка») на выходе получаем таблицу из двух столбцов:
1. Общее количество запросов по карте.
В этом SQL-запросе для каждой карты анализируется только общее число (количество) любых (успешных и неуспешных) авторизационных запросов за некоторую дату (как правило, предыдущий рабочий день, в понедельник — за пятницу, субботу и воскресенье, т.е. за все предыдущие рабочие дни).
Это очень простой запрос SQL, в нем для каждой карты нужно вычислить всего лишь общее число событий (авторизационных запросов, имевших место за анализируемый период (календарную дату)).
Например, у нас в портфеле банка 10 карт. Номера карт в примере соответственно от 0 до 9. Если по всем картам за определенную дату (день, предшествующий дате исполнения запроса) не было событий (авторизационных запросов), а по картам 2, 5 и 9 были соответственно 5, 2 и 6 запросов, на выходе в результате работы SQL-запроса (1 — Общее количество запросов по карте) будем иметь следующий результат:
Видно, что наибольшее число баллов (60) набрала карта № 9, так как именно по этой карте зафиксировано наибольшее число событий (авторизационных запросов, любых, не обязательно успешных в контексте данного запроса), что потенциально несет в себе больший риск (возможных финансовых потерь клиента или банка, если клиент — мошенник), чем по картам, не имевшим запросов или имевшим меньшее их число. Данное утверждение относится именно только к числу запросов, а не к общей их сумме или прочим аспектам (МСС, страна и пр.).
2. Общее количество запросов по карте с разбивкой по МСС высокого риска.
Существует устойчивое понятие «МСС повышенного риска» (МСС — merchant category code). К ним традиционно относят такие коды, как 5944, 7995, в последнее время — 6012, 8999 и пр. (на выбор разработчика БД-мониторинга). Официально МПС рассылают участникам ежеквартальные бюллетени, содержащие в том числе и списки МСС повышенного риска. Аналогично предыдущему SQL-запросу в данном анализируется количество событий, МСС которых совпадает с кодами повышенного риска. Точно так же следует начислять «штрафные» баллы по схеме, полностью совпадающей с изложенной выше, — чем больше запросов, тем больше баллов (можно составить таблицу значений начисляемых баллов даже для каждого МСС).
Это чуть более сложный SQL-запрос, в нем нужно анализировать и учитывать число запросов, исходивших из ТСП с определенным МСС, и в случае совпадения значений МСС, считающихся высокорисковыми, начислять соответствующее заданное в таблице МСС количество баллов.
Разработчикам СУБД следует иметь таблицу МСС с эмпирически заданными наперед значениями «штрафных» баллов, например для каждого запроса (успешного/неуспешного) из ТСП с МСС 5944 начислять карте 20 баллов, при запросе из ТСП с МСС 7995 — 100 баллов и т.д.
3. Общее количество запросов по карте в одном и том же терминале (ТСП).
В этом SQL-запросе анализируется количество запросов по карте, сделанных из одного и того же терминала (поле Terminal ID). Чем больше запросов, тем больше число баллов (подозрительно, когда одна и та же карта «гуляет» в одном и том же терминале, очень похоже на «прозвон» доступного остатка или потенциальное мошенничество). Обычно по одной и той же карте совершается 1–2 операции в одном терминале в день, как то предписано в Правилах и Требованиях МПС (оформить все покупки одной транзакцией). Для более жесткого соблюдения условий уникальности терминала можно анализировать еще и поле Acquirer ID, что гарантирует факт соблюдения формального требования МПС (предполагается, что у одного и того же эквайера не может быть терминалов с одинаковыми номерами).
Настройка оплаты по проекту «Пушкинская карта» в учреждении культуры
Ниже личный опыт настройки приема платежей в интернет-магазине, билетной системе организации культуры (ОК), до выпуска методических рекомендаций, с их выпуском всё описано полно и детально и они самый точный источник информации.
Во первых я бы рекомендовал ознакомиться с Правилами реализации проекта «Пушкинская карта», официальное название документа «Правила реализации мер по социальной поддержке молодежи в возрасте от 14 до 22 лет для повышения доступности организаций культуры» , документ написан простым и понятным языком, насколько это возможно для официального документа. Все другие документы обязательно ссылаются на правила, и фактически трактовка и объяснение правил.
Во вторых, Минкультом и Минцифры РФ утверждены методические рекомендации по техническому, технологическому внедрению проекта, это требования и правила, многие другие публикации также объяснения этих требований.
И третий источник информации, это чат в Телеграмм, там специалисты Минцифры РФ, и наверное все участники проекта со всей страны. Чат это уже база знаний с накопленными сообщениями, и возможность задать свой вопрос.
Общие рекомендации и ответы на вопросы по проекту «Пушкинская карта» по ссылке. Ссылка на нормативные документы по проекту «ПК» на сайте ПРО.Культура.РФ.
Единый фирменный стиль и брендбук по проекту «Пушкинская карта» находится по ссылке (имя: pushkin, пароль: fNuxIIdKVBlVcuzan4Oa).
Есть вопросы, мой телеграмм @otinoff
Базовые технические требования к учреждениям культуры
2. Возможность продажи билетов-онлайн
Подключена любая из онлайн-кассовых/билетных систем с обязательной
возможностью оплаты банковской картой платежной системы «Мир».
3. Наличие специально сканера для считывания QR-кода с билета
При оплате, номер телефона в заказе должен совпадать с номером телефона владельца Пушкинской карты.
Этапы технической настройки
Текст ниже личный опыт, а курсивом как эти шаги описаны в документе
Методические рекомендации по организационно-технологической подготовке организаций культуры и билетных операторов (агрегаторов) к участию в программе «Пушкинская карта»
в разделе 3
Порядок организационно-технологической подготовки организаций культуры и билетных операторов (агрегаторов) к участию в программе «Пушкинская карта»
1. Зарегистрируйтесь на ПРО.Культура.РФ
Зарегистрируйтесь на портале. Создайте карточку учреждения. Свяжитесь с технической поддержкой платформы «PRO.Культура.РФ» по номеру 8 (800) 200-37-17, чтобы в карточке вашего учреждения была поставлена специальная отметка «Пушкинская карта» об участии в проекте.
Зарегистрироваться на платформе «PRO.Культура.РФ» в соответствии с разделом «Как зарегистрироваться на платформе» руководства пользователя платформы, в случае если ОК/БО не были зарегистрированы на платформе «PRO.Культура.РФ» ранее;
2. Получите от банка-эквайера данные для настройки дополнительного платежного шлюза.
Данные это сначала тестовый, потом боевые логин и пароль для подключения интернет-магазина к платежному шлюзу.
Мы настраивали Сбербанк, готовый плагин Сбербанка позволяет подключить только один платежный шлюз, мы доработали его для возможности создания второго платежного шлюза и дополнительной кнопки оплаты.
Настроить и (или) доработать СПКБ ОК/БО для осуществления продажи билетов на мероприятия, включенные в реестр мероприятий, на сайте (сайтах) в сети Интернет, входящих в состав СПКБ ОК/БО, с использованием кнопки или ссылки «Оплатить «Пушкинской картой»;
3. Получите от банка эквайера данные для раздела Терминалы на ПРО.Культура.РФ
Данные для «белого терминала» это Acquirer ID, Merchant ID, Terminal ID, MCC нового терминала (у нас «правильный» оказался 7991, он прописан был в Почта Банка, если выдадут другой надо уточнять, иначе нервы время).
4. Зарегистрируйте «белый» терминал в разделе «Информация о терминалах».
Внести сведения (в том числе технические параметры) о «белых» УТД в личном кабинете ОК/БО на платформе «РКО.Культура.РФ» в соответствии с разделом «Как создать терминал» руководства пользователя платформы;
5. Создайте событие с подключенным терминалом
Создав мероприятие включив пункт Пушкинская карта и выбрав созданный терминал. приступайте к созданию событий в разделе «События». В анонсе мероприятия, проходящего в рамках программы «Пушкинская карта», необходимо поставить отметку «Участвует в проекте «Пушкинская карта» в специальном поле, заполнить поле «Терминал» и/или поле «Билетная система», указать цену и ссылку на покупку билетов. Затем нужно отправить событие на модерацию.
6. Пройдите двойную модерацию мероприятия
После создания мероприятия на ПРО.Культура.РФ оно проходит модерацию у редакторов портала (её, теоретически, можно ускорить если позвонить 8 (800) 200-37-17 в поддержку). После прохождения модерация будет отметка о прохождении. Потом вторая модерация у региональных экспертов, ее через региональное Министерство культуры можно ускорить. После прохождения модерация появится вторая отметка.
7. Настройте передачу данных в реестр проданных билетов
Далее пункты в методических рекомендациях, это Методические рекомендации по внесению и получению сведений
из реестра сведений о проданных билетах
Реестр проданных билетов это раздел на портале gosuslugi.ru. Текст инструкций по подготовке и проведению настройки и тестированию ниже, это:
Инструкции в виде PDF файлов с рабочими ссылками можно получить по звонку +7 495 647 1844 на горячую линию для бизнеса Почта.Банка. Скрыл ссылки на адреса реестров (это базы данных) и реестр тестирования (это гугл таблица онлайн), инструкции не опубликованы, их надо получать индивидуально.
Настроить и (или) доработать СПКБ ОК/БО для внесения и получения сведений из реестра сведений о проданных билетах в соответствии с Методическими рекомендациями по внесению и получению сведений из реестра сведений о проданных билетах;
Протестировать запросы можно в Postman
API для передачи информации в реестр сведений о билетах тут
RRN (Reference Retrieval Number) это referenceNumber в обмене по API, ссылочный номер транзакции, присваиваемый платёжным шлюзом после её завершения, N12, 12 знаков.
8. Получите ключ подписи запросов к промышленному реестру (боевой ключ)
9. Отправьте результаты тестирования в Почта.Банк
10. Почта.Банк одобряет проведение платежей по мерчанту проекта «Пушкинская карта»
Всё готово говорит Банк и если платежи идут (не забудьте, в заказе номер телефона должен совпадать с номером телефона владельца Пушкинской карты) открывайте шампанское.
Если нет, это нормально.
Известные проблемы:
Из личного кабинета банка (интернет эквайера), копируйте в текстом виде детали транзакции и отправляйте в Почта Банк.
Переписка, переписка и время шампанского всё равно настанет. У нас от начала до конца прошёл месяц.
Заключить с оператором соглашение о взаимодействии. (что делать описано в пункте 3.6)
Инструкция по передаче данных в реестр сведений о проданных билетах
Обращение необходимо заполнить по установленной форме (файл «Приложение 2. Форма подачи заявки»), указав:
• сведения об организации (название и ИНН);
• способ передачи (самостоятельно или через билетную систему/оператора, какую систему/оператора используете);
• дату и время отправки сведений в реестр;
• номера транзакций (RNN);
• номера записей о билетах, полученных при отправке «проблемных» билетов в реестр.
ВАЖНО! К обращению необходимо приложить выгруженный реестр сведений о переданных билетах накопительным итогом, начиная с 31 августа 2021 г., см. файл «Приложение № 3. Реестр билетов накопительным итогом».
Без передачи этих сведений срок ответа службы поддержки может быть увеличен.
Приложение 1. Тестирование интеграции с реестром билетов
версия 1.0.1 от 25.08.2021
Подготовка к тестированию
Проведение тестирования
При тестировании мы проверяем попадание информации в реестр по трем сценариям. Рекомендуем под каждый сценарий добавлять отдельный билет, не использовать ранее созданный.
1.Передача в реестр сведений о покупке
Метод API: Добавление билета в реестр.
Действия:
• Добавить билет
• Получить номер билета в ответе от API
Проверяется прохождение аутентификации в реестре, наличие обязательных полей в запросе «создание билета». Ключевые поля — сведения о покупке (идентификатор покупателя, сумма покупки, идентификатор мероприятия, RRN – номер транзакции в НСПК). Статус билета «Создан» (В API «active»).
2. Передача в реестр сведений о возврате билета.
Метод API: Вернуть билет
Действия:
• Добавить билет
• Получить номер билета в ответе от API
• Выполнить возврат билета
Проверяется изменение статуса билета на «возвращен» (в API «refunded»).
3. Передача в реестр сведений о гашении билета*
Метод АPI: Погасить билет
Действия:
• Добавить билет
• Получить номер билета в ответе от API
• Выполнить гашение билета.
Проверяется изменение статуса билета на «погашен» (в API «visited»).
*Только для билетных систем и организаций, самостоятельно реализующих билеты.
Остальные необходимые вашей организации методы вы можете протестировать самостоятельно.
Результаты тестирования
После проведения тестирования самостоятельно занесите в реестр тестирования сведения о методах и сценариях, которые вы протестировали.
Ежедневно (по рабочим дням) проводится проверка реестра тестирования и сверка с результатами теста в тестовом реестре билетов. При подтверждении корректности прохождения основных тестовых сценариев предоставляется токен к промышленному контуру реестра билетов. Токен предоставляется контактному лицу, указанному в реестре тестирования.
Информационная поддержка
При возникновении проблем/вопросов участник тестирования может адресовать их в группу Telegram «Пушкинская карта: Билеты» (в PDF файле ссылка на группу не верная, эта рабочая):
Ниже инструкция по подключению от Почта.Банка, выше пункты разобраны подробно, тут кратко.
ИНСТРУКЦИЯ ДЛЯ ПОДКЛЮЧЕНИЯ КАРТОЧНОГО ТЕРМИНАЛА, ПУШКИНСКАЯ КАРТА
Для предоставления возможности оплаты билетов на события, одобренные в программе «Пушкинская карта», картой этого проекта необходимо:
Есть вопросы, мой телеграмм @otinoff
Методические рекомендации по организационно-технологической подготовке организаций культуры и билетных операторов (агрегаторов) к участию в программе «Пушкинская карта» (скачать)
Методические рекомендации по получению сведений об устройствах терминального доступа, используемых для приема оплаты за билеты на мероприятия программы «Пушкинская карта» (скачать)
Методические рекомендации по внесению и получению сведений из реестра сведений о проданных билетах (скачать)
Методические рекомендации по получению сведений из реестра организаций культуры и реестра мероприятий (скачать)