СЕТЕВОЙ МОСТ ДЛЯ ЛОКАЛЬНОЙ АВТОРИЗАЦИИ ТРАНЗАКЦИЙ Российский патент 2020 года по МПК G06Q20/20 G06Q20/40 

УРОВЕНЬ ТЕХНИКИ

Транзакции по карте с хранимой суммой - такие как, но не в качестве ограничения, активации, деактивации, погашения, повторные загрузки и пополнения - типично требуют оконечного устройства с кассовым терминалом (POS), системы или компьютерного сетевого узла розничного торговца, чтобы поддерживать связь с удаленным процессором или сервером для получения авторизации применительно к транзакции и/или для проведения транзакции. Однако, в некоторых обстоятельствах, связь с удаленным процессором может не быть возможной (например, во время нарушений энергоснабжения или сетевых возмущений), или связи может временно не быть (например, во время пиковых периодов или перегрузок сети).

Поэтому, желательно предоставить системы и способы для локальных авторизации и/или проведения транзакций по карточке с хранимой суммой. Кроме того, желательно предоставить такие системы и способы, которые могут поддерживать связь, когда возможно, с удаленным процессором, чтобы обновлять процессор и какие-нибудь связанные хранилища данных новой информацией о транзакциях. Такие системы и способы могут давать возможность более быстрой обработки транзакций и запросов транзакции.

Различные системы карточек с хранимой суммой могут представлять некоторую степень локальной авторизации, которая может использоваться в крайне специфичных ситуациях. Однако, такие системы не обеспечивают возможность (i) продолжать давать обратный ход определенным типам транзакций при превышениях лимита времени, тем временем, к тому же, добавляя возможность замещающего одобрения для заданных типов транзакции; (ii) предлагать замещающие возможности для определенных «мягких отклонений», о которых сообщается; (iii) реализовывать конкретные требования, такие как предоставление уникального порядкового номера операции в платежной системе (STAN) по подлежащим отправке запросам, происходящим из транзакций с промежуточным хранением (SAF); и/или (iv) получать осведомленность по отношению к содержимому SAF для контроля на операционном уровне и уровне управления. Отметим, что, как правило, «мягкое отклонение» является отклонением, при котором процессор карточек с хранимой суммой может отклонять транзакцию, но выпускающая сторона или процессор (то есть, реальное средство авторизации для изделия и/или транзакции) мог не отклонять транзакцию.

Соответственно, такие требуемые показатели желательны у системы и способа в соответствии с некоторыми вариантами осуществления настоящего изобретения.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

Другие аспекты в соответствии с некоторыми вариантами осуществления настоящего изобретения могут включать в себя устройство для локальной обработки транзакций по карточке с хранимой суммой, причем устройство находится рядом с кассовым терминалом (POS) или компьютерным сетевым узлом розничного торговца, устройство находится на избирательной связи с POS или компьютерным сетевым узлом и процессором карточек с хранимой суммой, при этом устройство выполнено с возможностью: принимать запрос транзакции; определять, следует ли запрос транзакции пропустить напрямую в процессор карточек с хранимой суммой или принять по нему решение локально; по определению, что запрос транзакции следует пропустить напрямую в процессор карточек с хранимой суммой: передавать такой запрос в процессор карточек с хранимой суммой; по приему определенного ответа от процессора карточек с хранимой суммой или при неудавшейся связи с процессором карточек с хранимой суммой, локально отменять ответ процессора карточек с хранимой суммой или принимать решение по запросу транзакции локально; по определению, что запрос транзакции не следует пропускать напрямую в процессор карточек с хранимой суммой: локально принимать решение, посредством мостового процессора, по запросу транзакции; и передавать, посредством моста, ответ на запрос транзакции обратно в POS или компьютерный сетевой узел.

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Настоящее изобретение может быть полнее осознано по прочтению нижеследующего подробного описания вместе с прилагаемыми чертежами, на которых одинаковые указатели ссылок используются для обозначения идентичных элементов. Прилагаемые чертежи изображают некоторые иллюстративные варианты осуществления и могут помогать пониманию нижеследующего подробного описания. Прежде чем подробно разъяснен какой-нибудь вариант осуществления изобретения, должно быть осознано, что изобретение не ограничено в своем применении деталями конструкции и компоновками компонентов, изложенными в нижеследующем описании или проиллюстрированными на чертежах. Изображенные варианты осуществления должны пониматься в качестве примерных и ни в коем случае не ограничивающих общий объем изобретения. К тому же, должно быть понятно, что фразеология и терминология, используемые в материалах настоящей заявки, предназначены для целей описания и не должны рассматриваться в качестве ограничивающих. Подробное описание будет ссылаться на нижеследующие фигуры, на которых:

фиг. 1 иллюстрирует примерную модель с промежуточным хранением (SAF) с ограниченными функциональными возможностями обработки в соответствии с некоторыми вариантами осуществления настоящего изобретения;

фиг. 2 иллюстрирует примерную модель SAF с полными функциональными возможностями обработки в соответствии с некоторыми вариантами осуществления настоящего изобретения;

фиг. 3 иллюстрирует примерную блок-схему последовательности операций для сквозных операций в соответствии с некоторыми вариантами осуществления настоящего изобретения;

фиг. 4 излагает примерную последовательность операций для обработки мягкого отклонения с замещающим одобрением и без влияния на SAF в соответствии с некоторыми вариантами осуществления настоящего изобретения;

фиг. 5 иллюстрирует примерную последовательность операций для обработки мягкого отклонения с замещающим одобрением и жестким отклонением SAF в соответствии с некоторыми вариантами осуществления настоящего изобретения;

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

фиг. 7 изображает примерную последовательность операций для превышения лимита времени компьютерного сетевого узла с замещающим одобрением в соответствии с некоторыми вариантами осуществления настоящего изобретения;

фиг. 8 иллюстрирует примерный процессор для превышения лимита времени компьютерного сетевого узла с замещающим одобрением в соответствии с некоторыми вариантами осуществления настоящего изобретения;

фиг. 9 изображает примерную последовательность операций для режима приостановки в соответствии с некоторыми вариантами осуществления настоящего изобретения;

фиг. 10 иллюстрирует примерную последовательность операций для основанных инициатором лишений силы и обращений хода в соответствии с некоторыми вариантами осуществления настоящего изобретения;

фиг. 11 иллюстрирует примерную последовательность операций для ожидающей обработки транзакции SAF в соответствии с некоторыми вариантами осуществления настоящего изобретения;

фиг. 12 иллюстрирует примерную последовательность операций для комплементарной проводки в SAF в соответствии с некоторыми вариантами осуществления настоящего изобретения;

фиг. 13 иллюстрирует примерную последовательность операций для обработки продукта с универсальным кодом продукта (UPC), который не находится в пределах ожидаемого диапазона, в соответствии с некоторыми вариантами осуществления настоящего изобретения;

фиг. 14 иллюстрирует примерную последовательность операций для обработки продукта с универсальным кодом продукта, который не является действующим для системы SAF, в соответствии с некоторыми вариантами осуществления настоящего изобретения.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

Прежде чем подробно разъяснен какой-нибудь вариант осуществления изобретения, должно быть осознано, что настоящее изобретение не ограничено в своем применении деталями конструкции и компоновками компонентов, изложенными в нижеследующем описании или проиллюстрированными на чертежах. Настоящее изобретение является допускающим другие варианты осуществления и применение на практике или выполнение различными способами. К тому же, должно быть понятно, что фразеология и терминология, используемые в материалах настоящей заявки, предназначены для целей описания и не должны рассматриваться в качестве ограничивающих.

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

Со ссылкой на фиг. 1, в современных методологиях, если финансовая транзакция превышает лимит времени в компьютерном сетевом узле розничного торговца - например, тем временем ожидая ответа из процессора карточек с хранимой суммой - обращение хода по превышению лимита времени (TOR) может формироваться и выдаваться в систему SAF. Иначе, компьютерный сетевой узел поддерживает связь непосредственно с процессором карточек с хранимой суммой касательно других транзакций. С продолжающейся ссылкой на фиг. 1 и последовательность 10 операций, розничный торговец 110 может поддерживать связь непосредственно с процессором 120 карточек с хранимой суммой, который, в свою очередь, может поддерживать связь с поставщиком 130 услуг.

Поставщик 130 услуг может быть стороной, фактически выпускающей или изымающей карточку с хранимой суммой. Процессор 120 карточек с хранимой суммой может быть промежуточной стороной, которая может предоставлять услуги, связанные с множеством карточек с хранимой суммой. Розничный торговец 110 может быть типичным розничным торговцем или оптовым торговцем с местами для кассовых терминалов. Например, розничным торговцем 110 может быть Walgreens, который может предлагать для продажи множество карточек с хранимой суммой. Процессором 120 карточек с хранимой суммой может быть корпорация Interactive Communications International или InComm, которая может предусматривать активацию и другие услуги, связанные с множеством карточек с хранимой суммой, предлагаемых Walgreens. Поставщиком 130 услуг может быть хозяйствующий субъект, который обрабатывает транзакции по карточкам для выпускающего карточку - такой как Stored Value Solutions, который может обрабатывать транзакции по карточкам для подарочных карт Bed Bath & Beyond.

Во время большинства транзакций, компьютерный сетевой узел может действовать всего лишь в качестве сквозного прохода, при этом, он может передавать запросы 141 транзакции в процессор 120 карточек с хранимой суммой и может принимать ответы 142 из процессора 120 карточек с хранимой суммой. Однако, во время некоторых обстоятельств, может быть превышение 143 лимита времени при неудавшейся связи между компьютерным сетевым узлом 110 и процессором 120 карточек с хранимой суммой. В таких обстоятельствах, компьютерный сетевой узел 10 может формировать обращение 144 хода по превышению лимита времени, которое может выдаваться в очередь 145 SAF. В более позднее время, система SAF может связываться с процессором 120 карточек с хранимой суммой для обращения хода любой транзакции, которая могла быть проведена ненадлежащим образом или не полностью. По фиг. 1 может быть видно, что такие системы SAF имеют довольно ограниченные возможности.

В соответствии с некоторыми вариантами осуществления настоящего изобретения, может быть предусмотрен мост, который, в числе прочего, может обеспечивать одно или более из: (i) реализации замещающего одобрения на уровне компьютерного сетевого узла (вместо или в дополнение к уровню кассового терминала); (ii) предоставления возможности только специально идентифицированных типов транзакций (например, разрешения только замещающих активаций); (iii) предоставления возможности специально идентифицированных продуктов или комбинаций типов продукта-транзакции; (iv) автоматического предоставления мосту возможности поддерживать связь с системой SAF во время «мягких отклонений» и/или превышений лимита времени; и (v) предоставления результатов действий моста/SAF продавцу-консультанту или техническому специалисту, например, напечатанных на чеке или отображенных на устройстве отображения POS.

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

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

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

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

Системы и способы в соответствии с некоторыми вариантами осуществления по настоящему изобретению могут использовать один или более твердотельных накопителей. Например, твердотельные накопители могут содержать HP ProLiant DL380P G8 2U, который, например, может использовать процессоры Intel Xeon E5-2609. Твердотельные накопители могут быть на связи с POS/компьютерным сетевым узлом непосредственно, через один или более балансировщиков нагрузки и/или через мультиплексор.

Вообще, мост может реализовывать функциональные возможности передачи с временным хранением (SAF), чтобы проводить как замещающие, так и сквозные транзакции в местоположении розничного торговца. В соответствии с некоторыми вариантами осуществления настоящего изобретения, мост может предусматривать возможность (i) продолжать давать обратный ход определенным типам транзакций при превышениях лимита времени, тем временем, к тому же, добавляя возможность замещающего одобрения для заданных типов транзакции; (ii) предлагать замещающие возможности для определенных «мягких отклонений», о которых сообщается; (iii) реализовывать конкретные требования, такие как предоставление уникального STAN по подлежащим отправке запросам, происходящим из транзакций с промежуточным хранением (SAF); и/или (iv) получать осведомленность по отношению к содержимому SAF для контроля на операционном уровне и уровне управления.

Отметим, что модификации в системе розничного торговца могут быть желательны, рекомендованы или требоваться, чтобы мост предлагал полные функциональные возможности. Например, розничному торговцу может требоваться модифицировать настройки маршрутизации транзакций, чтобы направлять транзакции по карточке с хранимой суммой в мост - вместо прямо в процессор карточек с хранимой суммой. Подобным образом, розничный торговец может модифицировать свою систему, чтобы поддерживала новые коды ответа, связанные с замещающими одобрениями и замещающими отклонениями. Такие коды ответа могут быть полезны при отслеживании и соотнесении событий SAF и принятия решения мостом. К тому же, розничные торговцы могут выдавать дополнительные наставления по кассовому терминалу клиентам в определенных обстоятельствах. Например, если купленный продукт принимает замещающее одобрение, клиент может информироваться, что продукт будет активен в течение двадцати четырех (24) часов. Эта информация может доводиться устно (от продавца клиенту) или может быть напечатана на чеке.

Со ссылкой на фиг. 2, показана улучшенная модель 20 SAF, использующая мост, в соответствии с некоторыми вариантами осуществления настоящего изобретения. Вообще, модель 20 иллюстрирует различные транзакции, которые проводятся между клиентом 210, который может содержать POS 211 и/или компьютерный сетевой узел 212. (Отметим, что использование «клиента» здесь предназначено для указания ссылкой на оптового торговца или розничного торговца, который является клиентом процессора карточек с хранимой суммой. Например, розничный торговец, который предусматривает одну или более карточек с хранимой суммой или подарочных карт для продажи, может быть «клиентом»). Предполагается, что аналогичные транзакции могут проводиться с POS 211, поддерживающим непосредственную связь с мостом 220, хотя может быть обычной связь через компьютерный сетевой узел 212. Клиент 210 может направлять передачи в мост 220, который, в свою очередь может проводить некоторые транзакции либо может пропускать запросы транзакции напрямую в процессор 230 карточек с хранимой суммой. Процессор 230 карточек с хранимой суммой может поддерживать связь с поставщиком 240 услуг для предоставления возможности или проведения определенных транзакций.

Фиг. 2 излагает несколько примерных типов транзакции, чтобы проиллюстрировать прохождение через клиента 210, мост 220, процессор 230 карточек с хранимой суммой и поставщика 240 услуг. На 250, проиллюстрирована сквозная транзакция, в которой транзакция возникает в POS и пропускается через компьютерный сетевой узел 212, пропускается через мост 220 и принимается в процессоре 230 карточек с хранимой суммой. Процессор карточек с хранимой суммой может поддерживать связь с поставщиком 240 услуг, хотя также предполагается, что процессор 230 карточек с хранимой суммой также может быть поставщиком услуг или может быть авторизован проводить транзакции без дополнительных коммуникаций. Ответ транзакции затем направляется обратно в POS 211, через мост 220 и компьютерный сетевой узел 212.

На 251, ход транзакции указан для обстоятельств, в которых компьютерный сетевой узел превышает лимит времени (то есть, связь с процессором 230 карточек с хранимой суммой не способна быть результативной или своевременной), но определенный тип продукта (то есть, определенная карточка с хранимой суммой) не находится в списке «повторных». В этих обстоятельствах, транзакция может возникать в POS 211, проходит через компьютерный сетевой узел 212, но может не проходить процессор 230 карточек с хранимой суммой. Так как продукту может не быть разрешено проводиться мостом 220, обращение хода по превышению лимита времени (TOR) может выдаваться на 252, который может сохраняться в очереди 260 SAF для обмена информацией с процессором 230 карточек с хранимой суммой в более поздний момент времени.

На 253, ход транзакции указан для обстоятельств, в которых компьютерный сетевой узел превышает лимит времени, но определенный тип продукта находится в списке «повторных». Здесь, транзакция может возникать в POS 211, проходить через компьютерный сетевой узел 212, но может не проходить процессор 230 карточек с хранимой суммой. Однако, так как тип продукта находится в списке «повторных», мост 220 может выполнять замещающее одобрение транзакции на 254. Это замещающее одобрение также может сохраняться в очереди 260 SAF для более позднего обмена информацией с процессором 230 карточек с хранимой суммой.

На 255, ход транзакции указан для мягкого отклонения применительно к типу продукта, который находится в списке «повторных». Вновь, транзакция возникает в POS 211 и проходит через компьютерный сетевой узел 212. Мост 220 может выдавать замещающее одобрение 256 для транзакции и вновь может обновлять очередь 260 SAF.

На 257, ход транзакции показан для транзакций, которые авторизованы для проведения с использованием местного действия моста. Здесь, транзакция может возникать в POS 211, проходить через компьютерный сетевой узел 212, авторизоваться, одобряться или проводиться мостом 220. Вновь, мост 220 может выдавать информацию касательно любых замещающих одобрений или отклонений в очередь 260 SAF, чтобы поставлять обновления в процессор 230 карточек с хранимой суммой.

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

Для того чтобы клиент 210 надлежащим образом использовал такую систему SAF с мостом, клиент может быть осведомлен, что следует модифицировать систему. Такие модификации могут включать в себя, но не в качестве ограничения, предоставление возможностей (i) подтверждать действительность текущего содержимого очереди SAF по принятию решения; (ii) проводить различие «мягких» отклонений от «жестких» отклонений; и/или (iii) модифицировать поля при каждой попытке запроса SAF.

Точнее, для того чтобы подтверждать действительность текущего содержимого очереди SAF при принятии решения, принятие решения SAF может направляться конкретным текущим содержимым очереди SAF. Например, если принят запрос активации (или, подобным образом, принят запрос повторной загрузки) - в то время как запрос активации для той же самой карточки с хранимой суммой уже присутствует в очереди SAF, дополнительная или последующая транзакция должна быть локально отклонена.

Что касается проведения различия «мягких» отклонений от «жестких» отклонений, «мягкое» отклонение может быть кандидатом на возможные замещающие транзакции, проводимые мостом, тогда как «жесткое» отклонение не может быть. Поля в каждой попытке запроса SAF могут модифицироваться для предотвращения повторного или дубликатного использования одного и того же уникального порядкового номера операции в платежной системе (STAN). Использование одного и того же STAN может приводить в действие процессор карточек с хранимой суммой, чтобы автоматически повторял такой же ответ, как раньше. Соответственно, модификация STAN для каждого запроса транзакции - в частности, в случае мягких отклонений - может быть целесообразна.

Объединение в компьютерном сетевом узле

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

Конфигурация

Для того чтобы конфигурировать компьютерный сетевой узел для поддержания связи с мостом, могут быть полезны или необходимы несколько конфигурационных файлов. Например, участник транзакции 'QueryHost' может определять и управлять тем, как мост присоединяется к средству авторизации, и каким образом мост должен обрабатывать ответы или отсутствие ответов. Участник 'QueryHost' может называться как основным диспетчером транзакций (который может обрабатывать запросы в реальном времени), так и диспетчером транзакций SAF (который может обрабатывать последующую выгрузку проводок, которые попадают в очередь SAF, в результате конфигурационных решений).

В примере, приведенном ниже, и во всех примерных кодах или файлах, представленных в материалах настоящей заявки, отметим, что специфичные компоновка, алгоритмы и/или изложение информации являются всего лишь примерными. Многочисленные подходы или способы могут использоваться для достижения тех же, по существу тех же или аналогичных результатов. Более того, отметим, что примерные коды излагают InComm в качестве процессора карточек с хранимой суммой. Предполагается, что представленные коды могут быть модифицированы любым количеством способов, в том числе, заменой ссылок на «incomm» ссылками на другие участвующие стороны.

Участник 'QueryHost' может быть определен, как изложено ниже (отметим, что значения, изложенные ниже, являются примерными начальными значениями и не подразумеваются каким бы то ни было подтверждением окончательных промышленных настроек:

<participant class="com.ols.incomm.QueryHost" logger="Q2" realm="QueryHost">

<property name="mux" value="incomm-mux-pool" />

<property name="saf" value="incomm-svc-saf" />

<property name="threshold" value="3500" />

<property name="timeout" value="19000" />

<property name='retry-response-codes' value="91,92,96" />

<property name='retry-transaction-codes' value="189090" />

<property name="suspend-manager" value="suspend-manager" />

<property name="saf-on-disconnect" value="false" />

<property name="checkpoint" value="query-host" />

</participant>

Таблица 1, приведенная ниже, описывает свойства, заданные в QueryInCommHost.

Свойство Описание/использование mux (мультиплексор) Имя мультиплексора («mux»), который управляет подключением(ями) канала моста к этой конечной точке. Если mux-pool (группа мультиплексоров) сконфигурирована для конечной точки, взамен перечисляется ее имя.
Это значение может соответствовать имени, содержащемуся в соответствующем компоненте mux (или компоненте mux-pool) моста для этой конечной точки. Например, 22_incomm_mux_pool.xml имеет в качестве своей первой строки:
<muxpool class="org.jpos.q2.iso.MUXPool" logger="Q2" name="incomm-mux-pool"> saf Имя связанного диспетчера SAF
Это значение может соответствовать имени, содержащемуся в соответствующем компоненте SAF, SVCSAF=class. Например, 20_incomm_saf.xml может иметь в качестве своей первой строки: <saf name='inComm-svc-saf' logger='Q2' realm='saf' class='org.jpos.saf.SVCSAF'> threshold (пороговое значение) Время в миллисекундах, после которого транзакция может быть отклонена внутри (до вынесения решения о внешней авторизации). Например, перечисленное пороговое значение имеет значение 3,5 секунды. Поэтому, если накопленный таймер является большим, чем 3500 мс, в момент, обязательный для отправки, транзакция может быть отклонена внутри в мосте и устанавливать RC, равное 'D5'. timeout (превышение лимита времени) Время в миллисекундах, которое Query Host дает удаленному средству авторизации для выдачи ответа транзакции. Если ответ не принят в течение этого периода времени, транзакция считается являющейся запросом с превышенным лимитом времени. retry-response-codes (коды повторного ответа) Коды ответа, принятые из средства авторизации, которые могут приводить к трактованию мостом запроса в качестве доставленного неуспешно. Если Processing Code (код обработки) запроса определен в качестве кода «повтора», то запрос может считаться допускающим SAF, и проводка может регистрироваться в таблицах SAF. retry-transaction-codes (коды повторной транзакции) Список значений кодов обработки (то есть, 'PC', поля 3 по ISO8583), которые имеют значение «допускающий SAF», при любом из:
превышения лимита времени запроса в реальном времени; или
запроса в реальном времени, который принимает RC, равное значению, содержащемуся в 'retry-response-codes'
Например, если поле определено как: value=189090, то мост может вписывать строку в таблицы 'safMeta' и 'safData', запрашивающую повтор, если ситуации (a) или (b), приведенные выше, встречаются для одного из этих кодов транзакции.
Однако, для кодов транзакции, не включенных в этот список, мост может вписывать строку в таблицы SAF, запрашивающую обращение хода в сценарии (a) 'timeout' ('превышения лимита времени'); или пропускающую напрямую мягкое отклонение RC (обратно создателю транзакции) в сценарии (b) 'retry RC' ('RC повтора'.).
Отметим следующие исключения при обработке, которые могут существовать в рамках PC 189090 в некоторых установках с мостом:
189090 может представлять собой активацию, но также может представлять собой универсальную повторную загрузку проведением карты через считывающее устройство («повторную загрузку проведением через считыватель»). Несмотря на то, что активация является допускающей SAF транзакцией, повторная загрузка проведением через считыватель может не быть таковой.
Может не быть никакого другого определенного поля 189090, которое может предоставлять мосту возможность отличать активацию от повторной загрузки проведением через считыватель. Поэтому, для каждого клиента моста, который обрабатывает транзакции повторной загрузки проведением через считыватель, клиент и процессор карточек с хранимой суммой могут определять способ сигнализации.
Даже если 18909 определен в качестве кода повторной транзакции, мост может трактовать любой запрос, идентифицированный в качестве повторной загрузки проведением через считыватель, как если бы он был кодом транзакции, который не включен в этот список. suspend-manager (диспетчер приостановки) Имя компонента системы, который может управлять операциями 'suspend' ('приостановки') моста для конечной точки. Это значение может соответствовать имени, содержащемуся в соответствующем компоненте suspend моста для этой конечной точки. Например, 12_suspend_manager.xml может содержать строку: <suspend-manager class="com.ols.incomm.SuspendManager" logger-"Q2"> saf-on-disconnect (saf при разъединении) Установка значения, которая обозначает, желает или нет клиент осуществлять замещение, если все маршруты в конечную точку разъединены, условие, известное как «отсоединение мультиплексора».
Если установлено в 'false', все запросы транзакции возвращают код 'D4' отклонения во время отсоединения мультиплексора.
Если установлено в 'true', запросы транзакции с проводками вне списка 'retry-transaction-codes' возвращают 'D4' отклонения во время отсоединения мультиплексора; таковые в списке 'retry-transaction-codes' возвращают код одобрения, и проводка может быть помещена в SAF, чтобы отправляться, когда мультиплексор позднее снова присоединен. checkpoint (контрольная точка) Описательное имя для этапа участника транзакции, который может появляться в профайлере транзакции в отдельной записи q2.log для транзакции. Этот признак может указывать, за сколько времени (в миллисекундах) ответственен каждый участник в конкретной транзакции.

Определение диспетчера SAF

Конечная точка, принятая на обслуживание в мост, может требовать определенного и развернутого компонента диспетчера SAF. Такой диспетчер SAF может быть ответственен за (i) выгрузку очереди SAF; (ii) повторение репликации SAF; и (iii) синхронизацию SAF. Точнее, диспетчер SAF может идентифицировать записи SAF, которые все еще необходимо доставить в заданную конечную точку. Если имеется в распоряжении проводка для отправки, диспетчер SAF может размещать наиболее значимые записи в очереди (SAF.TXN) для обработки диспетчером транзакций SAF.

Репликация SAF может выполняться для однорангового узла в качестве части процесса выгрузки. Если репликация не удается (например, запрос в одноранговый узел превышает лимит времени), диспетчер SAF может размещать наиболее значимые записи в этом списке в очереди (RETRY.TXN) для обработки диспетчером повторных транзакций.

Если узел извещает, что его одноранговый узел не работает нормально, узел может начинать действовать в режиме 'SOLO' - в котором он ответственен за доставку записей SAF в оба узла. Впоследствии, когда узел распознает, что его одноранговый узел возобновляет работу, он далее должен синхронизировать с одноранговым узлом все действия, которые он предпринимал от его имени. Если происходит синхронизация, диспетчер SAF может помещать наиболее значимые записи в этом списке в очереди (SYNC.TXN) для обработки диспетчером транзакций синхронизации.

Например, для объединения конечной точки на подходе к мосту, определением диспетчера SAF может быть:

<saf name='bridge-saf' logger='q2' realm='saf' class='org.jpos.saf.SAFManager'>

<property name="endpoint" value="INCOMM" />

<property name="echo-mgr" value="incomm-echo-mgr" />

<property name="initial-delay' value='10000' />

<property name='penalty-box-time' value='300000' />

<property name='polling-delay' value='500' />

<property name='max-saf-space-queue-size' value='6' />

<property name='max-retry-space-queue-size' value='6' />

<property name='max-sync-space-queue-size' value='20' />

<property name='max-retransmissions' value='12' />

<property name='expire-after' value='43200'> in seconds </property>

<property name="node" value="1" />

<property name="peer-node" value="2" /<

</saf>

Таблица 2, приведенная ниже, описывает каждое из свойств, заданных в диспетчере SAF.

Свойство Описание/использование endpoint (конечная точка) Имя внешнего средства авторизации транзакций. Это значение может соответствовать значению, предусмотренному в аналогично именованном свойстве в участнике 'StoreInSAF' в соответствующем главном диспетчере транзакций для конечной точки. Это существует, так как таблица SAF может содержать в себе записи для более чем одного интерфейса внешней авторизации. echo-mgr (диспетчер эхо-сообщений) Имя компонента системы, который может управлять запросами 'echo' (эхо-сообщений) сетевого уровня моста в конечную точку. В ISO8583, есть сообщения серии '0800'.
Это значение может соответствовать имени, содержащемуся в соответствующем компоненте echo моста для этой конечной точки. Например, 15_incomm_echo_mgr.xml может содержать в себе строку <property name="echo-mgr" value="incomm-echo-mgr" /> initial-delay (начальная задержка) Время в миллисекундах, которое компоненты моста могут ожидать при запуске обслуживания (или повторном развертывании компонента) перед инициированием своего основного цикла логики. Например, значение '10000' (10 секунд) предоставляет приложению моста возможность полностью и комфортно запускаться до того, как могут быть инициированы операции SAF. penalty-box-time (время скамейки штрафников) Время в миллисекундах, которое мост может ожидать до повторной попытки отправки проводки из SAF, если предыдущая попытка отправить из SAF привела к результату 'retry'.
Это значение может быть важным механизмом регулирования скорости работы, поскольку оно может помогать гарантировать, что мост не обостряет заметные проблемы, испытываемые на средстве авторизации, нагружая частыми повторными попытками, которые имеют высокую вероятность неудачи. polling-delay (задержка опроса) Время в миллисекундах, которое ожидает мост после завершения своего основного цикла обработки перед новым запуском обработки. Если, при опросе списка проводок, мост определяет (a) что нет ничего имеющегося в распоряжении для отправки, он ожидает это время перед новым опросом; или (b) что есть одна или более имеющихся в распоряжении проводок для отправки, и он успешно обрабатывает с некоторым типом разрешения все из проводок в списке. В этом случае, мост может завершать свой главный цикл обработки и ожидать это время перед новым опросом. max-saf-space-queue-size (максимальный размер очереди пространства saf) Максимальное количество отдельных записей SAF, которое диспетчер SAF может помещать в очередь SAF («SAF.TXN») для доставки в конечную точку.
Аналогично 'inter-message-delay', это свойство может быть частью механизма регулирования скорости работы моста. Отметим, что может быть искушение установить здесь большое значение и выгружать очередь SAF как можно быстрее. Однако, это может заканчиваться усугублением первоначальных проблем, устанавливая чрезмерную нагрузку на средстве авторизации.
Слишком консервативное значение '1' также может вызывать беспокойство. Если проводка в верхней части очереди не может быть обслужена средством авторизации вследствие некоторой причины, уникальной для проводки, все другие ожидающие обработки проводки были бы заблокированы.
Умеренная настройка - такая как '6', может обеспечивать равновесие. max-retry-space-queue-size (максимальный размер очереди пространства повторов) Максимальное количество отдельных записей SAF, которое диспетчер SAF может помещать в очередь повторов ('RETRY.TXN') для доставки на одноранговый узел. max-sync-space-queue-size (максимальный размер очереди пространства синхронизации) Максимальное количество отдельных записей SAF, которое диспетчер SAF может помещать в очередь синхронизации ('SYNC.TXN') для доставки на одноранговый узел. max-retransmissions (максимальное количество повторных передач) Максимальное количество раз, которое мост может пытаться выгрузить конкретную проводку из очереди SAF. Мост может подсчитывать попытки повторной передачи в столбце 'attempts' таблицы 'safMeta'. Если достигнуто это пороговое значение, мост может маркировать запрос в качестве 'MAX' в столбце состояний, таким образом, убирая проводку из будущего рассмотрения. expire-after (теряет силу через) Время, в секундах, которое измеряется от метки времени, зарегистрированной в 'safMeta.created', через которое мост больше не будет пытаться отправлять конкретную проводку из таблицы SAF. Если достигнуто это пороговое значение, мост может маркировать запрос в качестве 'EXP' в столбце состояний, таким образом, убирая проводку из будущего рассмотрения. node (узел) Определение узла сервера, обрабатывающего запрос SAF. Когда отдельная запись SAF обработана диспетчером SAF, это значение может регистрироваться в столбце 'lastNode'. В нормальных операциях, каждый узел может быть ответственен за выгрузку своего собственного содержимого SAF. Если узел находится в режиме 'SOLO', такой узел может быть ответственен за выгрузку содержимого SAF обоих узлов. peer-node (одноранговый узел) Определение узла однорангового (то есть, другого) сервера, который составляет решение моста с двумя серверами.

Диспетчер эхо-сообщений

Системы и способы в соответствии с некоторыми вариантами осуществления настоящего изобретения также могут содержать диспетчер эхо-сообщений, который может управлять отправкой и приемом сообщений сетевого уровня (например, сообщений серии 08xx) между мостом и внешним средством авторизации (например, процессором карточек с хранимой суммой). Эхо-сообщение может служить по меньшей мере двум целям: (i) оно может поддерживать постоянно соединенные каналы действующими в промежутках времени с низким объемом (многие удаленные компьютерные сетевые узлы могут принудительно разрывать соединение спустя период неактивности; и/или (ii) оно может проверять внешнее средство авторизации и, по приему действительного ответа на эхо-запрос, может служить для вывода моста из режима приостановки. Участник диспетчера эхо-сообщений может быть определен, как изложено ниже.

<incomm-echo-manager class="com.ols.incomm.EchoManager" logger="Q2" >

<property name="persist-space" value="je:incomm-echo:space/incomm-echo" />

<property name="suspend-space" value="je:suspend:space/suspend" />

<property name="mux" value="incomm-mux" />

<property name="echo-mgr" value="incomm-echo-mgr" />

<property name="channel-ready" value="incomm.ready" />

<property name="timeout" value="19000" />

<property name="echo-interval" value="120000" />

<property name="max-timeouts" value="20" />

<property name="node" value="1" />

</incomm-echo-mgr>

Таблица 3, приведенная ниже, описывает каждое из свойств, заданных в Echo Manager.

Свойство Описание/использование persistent-space (постоянное пространство) Область хранения в памяти, используемая для сохранения текущего состояния диспетчера эхо-сообщений. suspend-space (пространство приостановки) Область хранения в памяти, используемая для сохранения текущего состояния режима 'suspend'. mux (мультиплексор) Имя мультиплексора, который управляет подключением(ями) канала моста к этой конечной точке. Это значение должно соответствовать имени, содержащемуся в соответствующем компоненте mux моста для этой конечной точки. Например, 20_incomm_mux.xml имеет в качестве своей первой строки: <mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="incomm-echo-mgr"/> channel-ready (имеющиеся в наличии каналы) Список всех каналов под управлением мультиплексора этой конечной точки. timeout (превышение лимита времени) Время в миллисекундах, которое QueryHost дает удаленному средству авторизации на предоставление ответа на эхо-запрос. Если ответ не принят в течение этого периода времени, транзакция считается превысившим лимит времени запросом. echo-interval (интервал эхо-сообщений) Время в миллисекундах между эхо-запросами max-timeouts (максимальное количество превышений лимита времени) Количество следующих друг за другом превышений лимита времени (на клиентских запросах транзакции, запросах несетевого уровня), возможность которого может предоставлять мост перед установкой приложения в режим 'suspend'. Впоследствии диспетчер эхо-сообщений может использовать прием действительного ответа на эхо-запрос для вывода моста обратно из режима 'suspend'. node (узел) Определение узла сервера (то есть, '1' или '2')

Формируемые мостом коды ответа

Если мост выступает посредником в транзакции и предпринимает какое-нибудь действие, он может отправлять код ответа ('RC' - поле 39) обратно в клиентское приложение в ответе. Эти 'RC Slates' ('реестры кодов ответа') предназначены для обеспечения понимания в отношении принятия решения мостом и выдачи указания клиентскому компьютерному сетевому узлу в отношении любых следующих этапов, которые могут быть предприняты.

Реестр одобрений моста может быть в форме 'Bx'. Клиентское приложение может трактовать любой ответ, в котором RC='Bx' (например, B1, B1, и т.д.) в качестве одобренной транзакции. Таблица 4 ниже иллюстрирует некоторые из кодов одобрения реестра B.

Код Смысл SAF Обращение хода B0 Замещающее одобрение при отклонении. Мост принял RC из средства авторизации, который находится в списке 'retry-response-codes'; код обработки ('PC') находится в списке 'retry-transaction-codes'. Y N B1 Замещающее одобрение при превышении лимита времени. Мост превысил лимит времени, ожидая ответа из средства авторизации; PC находится в списке 'retry-transaction-codes' Y N B2 Замещающее одобрение при ожидающей обработки комплементарной проводке SAF. Мост может идентифицировать ожидающую обработки комплементарную транзакцию по карточке в SAF, тем временем, обрабатывая новый запрос для карточки. Например, если принят запрос деактивации, и запрос деактивации ожидает обработки в SAF, текущий запрос должен быть помещен в SAF, чтобы также гарантировать, что средство авторизации принимает запросы в надлежащем порядке. Y N B3 Замещающее одобрение при приостановке моста Мост находится в режиме 'suspend' вследствие достижения установки 'consecutive-timeouts'; PC находится в списке 'retry-transactions-codes'. Y N B4 Принудительное одобрение/допущенное обращение хода Мост может принимать тип 0400 сообщений (лишение силы или другое сформированное системой обращение хода) от клиента и может 'допускать' ('accept') его (то есть, помещать его непосредственно в свой SAD для последующей доставки).
(Примечание: существует исключение в обработке, которое включает в себя какой-нибудь 0400 из повторной загрузки проведением через считыватель, принятой от клиента. Вместо помещения этих запросов транзакции непосредственно в SAF, мост может выполнять 'one shot live' (то есть, мост может делать попытку немедленной доставки). Если такая первая попытка сталкивается с условием повтора, то может применяться принудительное правило 'B4'. Y Y B5 Дубликатное одобрение. Мост может идентифицировать запрос деактивации для карточки в SAF, тем временем, обрабатывая новый запрос деактивации от клиента. N N B6 Одобрение при отсоединении мультиплексора. Все линии от моста до средства авторизации на данный момент разъединены; PC находится в списке 'retry-transactions-codes'. Y N

Отметим, что для кодов B0, B1, B2, B3 и B6, клиентское приложение должно давать команду системе POS уведомлять клиента (устно или печатать на чеке), что продукт будет доступен для использования в течение двадцати четырех (24) часов.

Реестр отклонений моста может быть в форме 'Dx'. Клиентское приложение может интерпретировать любой ответ, в котором RC='Dx', в качестве отклоненного ответа. Таблица 5 ниже иллюстрирует некоторые из кодов отклонения реестра D.

Код Смысл SAF Обращение хода D1 Отклонение при ожидающем обработки SAF. Мост идентифицировал ожидающий обработки запрос активации для карточки в SAF, тем временем, обрабатывая новый запрос активации от клиента. N N D2 Отклонение при превышении лимита времени запрашиваемого удаленного компьютерного узла. Мост превысил лимит времени, тем временем, ожидая ответа из средства авторизации; PC не находится в списке 'retry-transaction-codes'. Y Y D3 Отклонение при приостановке моста. Мост был установлен в режим 'suspend' вследствие достижения установки 'consecutive-timeouts'; PC не находится в списке 'retry-transaction-codes'. N N D4 Отклонение при отсоединении мультиплексора. Все маршруты из моста в средство авторизации разъединены. N N D5 Отклонение при пороговой ошибке моста. Мост был неспособен направить транзакцию для внешней авторизации до достижения заданного порогового периода; была инициирована резервная защита. N N D6 Отклонение при UPC, меньшем, чем определенная минимальная величина. Этот необязательный код представляет собой сценарий, в котором иной результат допускающей SAF транзакции не достигнут вследствие запроса на сумму, меньшую, чем определенная минимальная сумма для UPC. N N D7 Отклонение при UPC, большем, чем определенный максимум. Этот необязательный код представляет собой сценарий, в котором иной результат допускающей SAF транзакции не достигнут вследствие запроса на сумму, большую, чем определенная максимальная сумма для UPC. N N D8 Проводка не активна для SAF; замещающее одобрение при мягком отклонении не выполняется. Этот необязательный код представляет собой сценарий, в котором иной результат допускающей SAF транзакции не был достигнут вследствие проводки, маркированной как 'SAF=N' в поставляемом клиентом файле. N N D9 Проводка не активна для SAF; замещающее одобрение при превышении лимита времени не выполняется. Этот необязательный код представляет собой сценарий, в котором иной результат допускающей SAF транзакции при превышении лимита времени не был достигнут вследствие маркировки проводки в качестве 'SAF=N' в поставляемом клиентом файле. Y Y DA Отклонение при повторной загрузке проведением через считыватель. Этот условный код используется, чтобы показывать, что иной результат допускающей SAF транзакции не был достигнут вследствие ограничений повторной загрузки проведением через считыватель. N N

Отметим, что определенный текст об отклонении может выдаваться на устройство отображения POS. Например, если выдан код D1 отклонения, устройство отображения может показывать «Исходный запрос допущен» («Original request accepted»). Если выданы D2, D3, D4, D5, D8, D9 или DA, устройство отображения может показывать «Попробуйте еще раз прямо сейчас» («Try again momentarily»). Если выданы D6 или D7, устройство отображения может показывать «Некорректная сумма для продукта» («Amount incorrect for product»).

Определения таблиц базы данных

Мост может регистрировать результаты и метрическую информацию в таблице tranlog журнала транзакции («tranlog»). Мост может быть выполнен с возможностью выполнять «более тяжелый вариант», где он регистрирует запись tranlog для каждой транзакции, которую он видит, независимо от того, активизирует ли он SAF или нет; или «более легкий вариант», где он регистрирует запись tranlog только для транзакций, в которых он активизирует SAF. Выбор сообщается через свойство 'log-safed-only' в участнике CreateTranLog основного диспетчера транзакций:

<participant class="com.ols.jpos.CreateTranLog" logger="Q2" realm="CreateTranLog>

<property name="queue" value="MAIN.TXN" />

<property name="space" value=tspace:default" />

<property name="server" value="@server@" />

<property name="log-safed-only" value="true" />

<property name="checkpoint" value-"create-tranlog" />

</participant>

Во время конфигурирования моста и его характеристик, может выбираться более тяжелая конфигурация (при этом, значение='false'), если клиент нуждается в зарегистрированном доказательстве влияния моста на длительность транзакции и все остальное. Наоборот, клиент может предпочесть более легкую конфигурацию (при этом, значение='true'), если клиент желает минимизировать следы моста, как при оказании воздействия на транзакции, так и при ведении соответствующей базы данных. Вообще и в соответствии с некоторыми вариантами осуществления настоящего изобретения, таблица 'tranlog' может быть определена, как изложено ниже:

CREATE TABLE [dbo].[tranlog](

[id] [numeric](19, 0) IDENTITY(1,1) NOT NULL,

[date] [datetime] NULL,

[irc] [varchar](4) NULL,

[rrc] [varchar](4) NULL,

[rc] [varchar](4) NULL,

[duration] [numeric](19, 0) NULL,

[extDuration] [numeric](19, 0) NULL,

[outstanding] [int] NULL,

[node] [varchar](1) NULL,

[pc] varchar'(6) NULL,

[extrc] [varchar](255) NULL,

[peerDuration] [numeric](19, 0) NULL,

PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (PAD_INDEX=OFF, STATISTICS_NORECOMPUTE=OFF, IGNORE_DUP_ KEY=OFF, ALLOW_ROW_LOCKS=ON, ALLOW_PAGE_LOCKS=ON) ON [PRIMARY]

) ON [PRIMARY]

GO

Таблица 6, приведенная ниже, описывает свойства, заданные в tranlog.

Свойство Описание/использование id (идентификатор) ID строки автоматически формируется сервером MS SQL. date (дата) Метка времени того, когда отдельная запись была записана в таблицу SAF.
[Примечание: в отличие от значения 'safMeta.created', эти отдельные записи могут не быть 'normalized' ('нормализованы') для протоколирования в журнале за полную секунду (то есть, миллисекунды не установлены в '000', но, взамен, могут регистрироваться с точностью уровня миллисекунд). irc Код внутреннего результата ('IRC') моста. Внутреннее значение, которое может быть предназначено только для использования процессором карточек с хранимой суммой. rrc Код ответа, возвращаемый внешним средством авторизации, то есть, код удаленного ответа ('RRC'). Отметим, что это значение может возвращаться средством авторизации по первому запросу или в реальном времени. Последующие RRC могут возвращаться из средства авторизации в ответ на подвергнутые SAF запросы, которые помещены в 'safMeta.lastRRC'. rc Код ответа ('RC'), который мост может возвращать в клиентский компьютерный сетевой узел в ответе в реальном времени. Это значение может быть подаваемым внешним средством авторизации, или - в ситуации, где мост выступает посредником - одним из значений реестра Bridge-generatorRC. duration (длительность) Длительность в миллисекундах транзакции от момента времени, когда она принята мостом, до момента времени, когда она зарегистрирована в tranlog. Может включать в себя «внеблочные» компоненты (смотрите следующие два значения). extDuration (внешняя длительность) Длительность в миллисекундах транзакции от момента времени, когда она принята мостом, до момента времени, когда ожидает ответа в течение этого интервала. Значение 'extDuration' может быть включено в значение 'duration'.
Отметим, что, в некоторых условиях, мост может принимать локальное решение по транзакции и не вовлекать внешнее средство авторизации. В этих случаях, extDuration может регистрироваться в качестве 0. outstanding (ожидающие выполнения) Глубина очереди транзакций MAIN.TXN, когда обслуживалась эта проводка.
В хорошо функционирующей реализации, этим значением типично был бы '0' или некоторое небольшое число. Большее число может быть указанием, что необходимо сконфигурировать дополнительные сеансы в основном диспетчере транзакций, или что внешнее средство авторизации отвечает на запросы очень медленно во время пикового периода. node (узел) Полное имя сервера, который обрабатывал транзакцию. pc Код обработки ('PC', поле 3 по ISO8583) запроса, отправленного во внешнее средство авторизации. Например, значения PC, подобные '189090' (активации); '199090' (повторной загрузке); '289090' (деактивации), могут использоваться процессором карточек с хранимой суммой. extrc Дополнительный пояснительный текст о конкретных RC без одобрения, выдаваемый, когда требуется. peerDuration (одноранговая длительность) Длительность в миллисекундах времени, которое транзакция тратит в одноранговом узле, реплицируя содержимое SAF. Мост может ожидать ответа в течение этого интервала. Значение 'peerDuration' включено в значение 'duration'.
Отметим, что, если транзакция не помещена в SAF, одноранговая длительность имеет значение 0 по определению. Репликация может не требоваться.

В соответствии с некоторыми вариантами осуществления настоящего изобретения, и для того чтобы удовлетворять конкретным требованиям (например, изменения STAN по исходящим запросам, происходящим из SAF, проверки очереди SAF касательно связанных отдельных записей для непосредственной специфичной обработки), машина обработки в реальном времени моста может записывать (и впоследствии обновляет) ('допускающие SAF') проводки 'SAF-able' в виде строк в две взаимосвязанные таблицы базы данных, таблицу safMeta и таблицу safData. Каждая, в свою очередь, обсуждена ниже.

Таблица safMeta может содержать ('мета') данные 'meta' об отдельной записи SAF (например, 'endpoint'), а также динамические данные, связанные с отдельной записью, то есть, значения, которые мост может обновлять после каждой попытки SAF (например, 'lastSent', 'lastStan'). Дополнительно, любое поле, которое мост использует в качестве части основанного на SAF запроса базы данных, должно располагаться в этой таблице 'Meta'.

Подобным образом, таблица safData может содержать в себе защищенное представление запроса SAF, а также статические данные, связанные с отдельной записью (например, 'reversal', 'inboundStan')

Запись в строку этих таблиц может происходить в одной или более из следующих ситуаций: (a) ответ транзакции принят из средства авторизации, в котором код удаленного ответа ('RRC') перечислен в качестве одного из 'retry-response-codes', а соответствующий код транзакции у транзакции перечислен в 'retry-transaction-codes'; (b) ответ транзакции не был принят из средства авторизации (то есть, произошло превышение лимита времени), и соответствующий код транзакции у транзакции перечислен в 'retry-transaction-codes'; (c) при подготовке запроса транзакции, обнаруживается, что все линии в средство авторизации были разъединены (сценарий отсоединения мультиплексора), и клиент моста сконфигурировал систему в виде 'saf-on-disconnect' со значением 'true'; (d) запрос принят от клиента, и определено, что был комплементарный неотправленный запрос для той же самой карточки в таблице SAF; (e) ответ транзакции не был принят из средства авторизации (то есть, произошло превышение лимита времени, и соответствующий код транзакции у транзакции не перечислен в 'retry-transaction-codes' (или перечислен, но мост идентифицировал запрос в качестве повторной загрузки проведением через считыватель); или (f) основанное на конечном устройстве обращение хода по превышению лимита времени или лишение силы/аннулирование клиента были приняты из кассового терминала. Отметим, что (a)-(e) могут упоминаться как 'host-based timeout reversals' ('основанные на компьютерном сетевом узле обращения хода по превышению лимита времени') и соответственно могут указываться ссылкой как TOR.

В ситуациях (a)-(d), приведенных выше, исходная транзакция может быть проводкой, записанной в таблицу, тем временем, столбец обращения хода в строке может быть установлен в 'false'. В ситуации (e), исходная транзакция может быть проводкой, записанной в таблицу, и столбец обращения хода в строке может быть установлен в 'true'. В ситуации (f), обращение хода исходной транзакции может приниматься непосредственно из POS, и проводка может записываться в таблицу, в то время как столбец обращения хода в строке может быть установлен в 'true.' В каждой из ситуаций, состояние проводки, когда записывается в таблицу в первый раз машиной обработки в реальном времени, может быть установлено в 'RETRY.'

Впоследствии и асинхронно, диспетчер SAF может читать эту таблицу, чтобы определять, какая строка может содержать в себе кандидатов, все еще пригодных для доставки. Пригодный кандидат может быть тем, в котором проводка (i) не утратила силу; (ii) не достигла максимального количества повторных попыток; (iii) не доставлялась успешно раньше; и/или (iv) не вызывала исключение при обработке во время предыдущей попытки отправки. Соответственно, проводки, которые остаются в состоянии 'RETRY', могут быть пригодными кандидатами для доставки.

В соответствии с некоторыми вариантами осуществления настоящего изобретения, таблица 'safMeta' может быть определена, как:

CREATE TABLE [dbo].[safMeta](

[id] [mumeric](19, 0) IDENTITY(1,1) NOT NULL,

[tranId] [numeric] (19, 0) NOT NULL,

[node] [varchar] (1) NOT NULL,

[endpoint] [varchar] (20) NOT NULL,

[hash] [varchar] (255) NOT NULL,

[status] [varchar] (5) NOT NULL,

[created] [datetime] NOT NULL,

[pc] [varchar] (6) NOT NULL,

[lastSent] [datetime] NULL,

[lastRRC] [varchar] (2) NULL,

[lastStan] [varchar] (12) NULL,

[lastNode] [varchar] (1) NULL,

[LastAuthId] [varchar] (20) NULL,

[attempts] [int] NULL,

[repStatus] [varchar] (5) NULL,

[repRetryReason] [varchar] (4) NULL,

[repPhase] [varchar] (1) NULL,

[repTime] [datetime] NULL,

[archiveId] [numeric] (19, 0) NOT NULL DEFAULT 0,

[extractId] [numeric] (19, 0) NOT NULL DEFAULT 0,

PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (PAD_INDEX=OFF, STATISTICS_NORECOMPUTE=OFF, IGNORE_DUP_KEY=OFF, ALLOW_ROW_LOCKS=ON, ALLOW_PAGE_LOCKS=ON) ON [PRIMARY]

) ON [PRIMARY

GO

CREATE NONCLUSTERED INDEX [pending] ON [dbo].[safMeta]

(

[hash] ASC,

[status] ASC,

[endpoint] ASC

) WITH (PAD_INDEX=OFF STATISTICS_NORECOMPUTE=OFF, SORT_IN_TEMPDB=OFF, DROP_EXISTING=OFF, ONLINE=OFF, ALLOW_ROW_LOCKS=ON, ALLOW_PAGE_LOCKS=ON) ON [PRIMARY]

GO

CREATE NONCLUSTERED INDEX [toSend] ON [dbo].[safMeta]

(

[created] ASC,

[status] ASC,

[endpoint] ASC,

[node] ASC

) WITH (PAD_INDEX=OFF, STATISTICS_NORECOMPUTE=OFF, SORT_IN_TEMPDB=OFF, DROP_EXISTING=OFF, ONLINE=OFF, ALLOW_ROW_LOCKS=ON, ALLOW_PAGE_LOCKS=ON) ON [PRIMARY]

GO

CREATE NONCLUSTERED INDEX [toRetry] ON [dbo].[safMeta]

(

[created] ASC,

[status] ASC,

[endpoint] ASC,

[node] ASC

) WITH (PAD_INDEX=OFF, STATISTICS_NORECOMPUTE=OFF, SORT_IN_TEMPDB=OFF, DROP_EXISTING=OFF, ONLINE=OFF, ALLOW_ROW_LOCKS=ON, ALLOW_PAGE_LOCKS=ON) ON [PRIMARY]

GO

CREATE NONCLUSTERED INDEX [toUpdate] ON [dbo].[safMeta]

(

[tranId] ASC,

[node] ASC

) WITH (PAD_INDEX=OFF, STATISTICS_NORECOMPUTE=OFF, SORT_IN_TEMPDB=OFF, DROP_EXISTING=OFF, ONLINE=OFF, ALLOW_ROW_LOCKS=ON, ALLOW_PAGE_LOCKS=ON) ON [PRIMARY]

GO

Таблица 7, приведенная ниже, описывает каждое из свойств, заданных в таблице safMeta.

Свойство Описание/использование id (идентификатор) ID может формироваться автоматически сервером MS SQL tranid (идентификатор в tranlog) Значение 'id' связанной отдельной записи tranlog моста node (узел) Узел ('1' или '2'), который обрабатывал исходный связанный запрос транзакции и помещал проводку в SAF endpoint (конечная точка) Имя конечной точки средства авторизации, в случае переключения. Это значение может соответствовать запротоколированному в журнале 'tranlog.endpoint' и может записываться в нем, также поскольку связанные с SAF таблицы могут содержать в себе отдельные записи для одного или более внешних интерфейсов. hash (хэш-сумма) Необратимая усложненная хэш-сумма SHA-512 первичного номера счета (PAN) продукта карточки с хранимой суммой, содержащаяся в запросе транзакции. Это значение может быть важным, для того чтобы содействовать предотвращению отправки запросов в реальном времени для любого PAN, в котором активные проводки (состояние='RETRY' или 'PEND') с таким PAN остаются в таблицах SAF. Запросы в реальном времени, которые могут блокироваться вследствие этого ограничения, могут получать сформированный мостом код отклонения RC со значением 'D1.' status (состояние) RETRY: Начальное состояние отдельной записи, когда записывается (или обновляется, когда RC находится в списке 'retry')
PEND: Отдельная запись может быть в активном состоянии; ожидая ответа
MAX: Отдельная запись достигла максимального счета повторов
EXP: Отдельная запись достигла установки истечения срока действия
TAKEN: Отдельная запись получила действительный RC (или код, не заданный в списке 'retry')
ISOEX: Отдельная запись сформировала исключение во время обработки created (создана) Метка времени того, когда отдельная запись была записана в таблицы SAF в первый раз. Эта отдельная запись может быть нормализована, чтобы протоколировать в журнале полную секунду, так чтобы столбец мог эффективно использоваться в качестве индексного компонента. pc Код обработки ('PC', поле 3 по ISO8583) запроса, отправленного во внешнее средство авторизации. lastsent (отправлено в последний раз) Метка времени того, когда отдельная запись была отправлена в средство авторизации в последний раз. lastRRC (последний RRC) Код удаленного результата ('RRC', код результата, который может выдаваться внешним средством авторизации), полученный в ответ на последний запрос повтора. Отметим, что это значение может быть установлено в NULL, если последний запрос повтора не получал ответа в течение выделенного периода превышения лимита времени. lastStan (последний уникальный порядковый номер операции в платежной системе) Уникальный порядковый номер операции в платежной системе (STAN), вставленный мостом в поле 11 по ISO8583 при последней попытке повтора транзакции. Отметим, что, в соответствии с некоторыми вариантами осуществления настоящего изобретения - в некоторых обстоятельствах - STAN должен быть изменен при повторе для предотвращения риска получения повторных мягких отклонений. lastNode (последний узел) Узел из которого была отправлена последняя попытка SAF. В нормальных ('NORMAL') операциях, каждый узел может быть ответственен за выгрузку своего собственного содержимого SAF. В режиме 'SOLO', узел может быть ответственен за выгрузку содержимого SAF обоих узлов lastAuthId (идентификатор последней авторизации) ID авторизации (поле 38), принятый из процессора карточек с хранимой суммой или внешнего средства авторизации в последнем ответе транзакции. attempts (попытки) Количество повторов для отдельной записи на сегодняшний день repStatus (состояние репликации) Состояние попытки репликации (в одноранговый узел). Это значение может быть уместным только в инициирующем узле.
RETRY: Начальное состояние отдельной записи, когда записывается в таблицу; отдельная запись может оставаться в этом состоянии, если попытка репликации попадает в ситуации 'SOLO', 'DISC' или 'TOUT'.
PEND: Попытка репликации находится в активном состоянии и ожидает ответа
SENT: мост успешно реплицировал отдельную запись SAF в одноранговый узел
FAIL: попытка репликации не удалась и не будет предпринята повторно repRetryReason (причина повтора репликации) Если repStatus='RETRY', этот столбец обозначает почему. Это поле также может содержать в себе причину неуспеха, если repStatus='FAIL'. Это значение уместно только в инициирующем узле.
SOLO: узел был работающим в режиме 'SOLO', когда инициировал или обновлял SAF
DISC: узел не был присоединен к своему одноранговому узлу, когда он инициировал или обновлял SAF
TOUT: узел превысил лимит времени своего однорангового узла, тем временем ожидая ответа на запрос репликации
NOTF: узел пытался обновить отдельную запись в своем одноранговом узле, но одноранговый узел сообщил, что он не может найти отдельную запись. Это может использоваться в связи с repStatus='FAIL' repPhase (фаза репликации) Фаза попытки репликации в одноранговый узел. Значение уместно только в инициирующем узле.
O: Оригинал - узел реплицировал (или пытается реплицировать) оригинальный экземпляр отдельной записи SAF, например, когда мост принимает свое первое решение по транзакции.
U: Обновление - узел реплицировал (или пытается реплицировать) оригинальный экземпляр, например, когда он принял одобрение из средства авторизации по подвергнутому SAF запросу. repTime (время репликации) Метка времени того, когда мост в последний раз инициировал попытку репликации для отдельной записи. archiveId (идентификатор архивирования) ID прогона задания архивации, который записал эту запись в архивный файл extractId (идентификатор извлечения) ID прогона задания извлечения, который принял решение, следует ли выдавать эту запись в файл исключений. Задание извлечения может маркировать любую завершенную запись, которая является исключением (то есть, в тех случаях, когда состояние имеет значение 'EXP', 'MAX' или 'ISOEX'; или состоянием является 'TAKEN', а lastRRC имеет значение не '00' в виде +reconId (например, 156). Задание извлечения может маркировать любую завершенную, которая не является исключением (то есть, состояние имеет значение 'TAKEN', а lastRRC имеет значение '00' в виде - reconId (например, - 156). Задание может не маркировать никакую незавершенную запись (то есть, состояние имеет значение 'RETRY' или 'PEND').

Как обсуждено выше, таблица safData также может быть определена.

CREATE TABLE [dbo].[safData](

[id] [numeric] (19, 0) NOT NULL,

[secureData] [varbinary] (8000) NULL,

[keyId] [varchar] (7) NULL,

[reversal] [tinyint] NULL,

[inboundStan] [varchar] (12) NULL,

[rrn] [varchar] (12) NULL,

[amount] [numeric] (14, 2) NULL,

PRIMARY KEY CLUSTERED

(

[id] ASC

) WITH (PAD_INDEX=OFF, STATISTICS_NORECOMPUTE=OFF, IGNORE_DUP_KEY=OFF, ALLOW_ROW_LOCKS=ON, ALLOW_PAGE_LOCKS=ON) ON [PRIMARY]

) ON [PRIMARY]

GO

Таблица 7, приведенная ниже, описывает каждое из свойств, заданных в таблице safMeta.

Свойство Описание/использование id (идентификатор) Здесь может быть распространен ID строки, который может автоматически формироваться сервером MS SQL для 'safMeta' secureData (защищенные данные) Зашифрованный вариант полного подвергнутого SAF запроса, подлежащего отправке в средство авторизации. Мост может шифровать данные, например, с использованием сертифицированной PA-DSS методологии, которая может содержать в себе в качестве отличительного признака подход передаваемого уникального ключа транзакции ('DUKPT') с тройным DES keyId (идентификатор ключа) Идентификатор ключа базового происхождения ('BDK'), используемого для шифрования содержимого столбца secureData с использованием методологи шифрования моста. reversal (обращение хода) Флажковый признак, указывающий, является ли исходная попытка запроса транзакции подлежащей повторению (установлен в 'FALSE'), или обращение хода исходной попытки (установлен в 'TRUE') inboundStan (внутренний уникальный порядковый номер операции в платежной системе) STAN, принятый мостом в поле 11 по ISO8583 в инициирующем внутреннем запросе. STAN здесь может регистрироваться для выдачи отчетов, которые могут предоставлять всем сторонам возможность согласовывать транзакции RRN Справочный номер обращения хода (RRN), принятый мостом в поле 37 по ISO8583 в инициирующем внутреннем запросе. Это также может регистрироваться для содействия согласованию между всеми сторонами amount (сумма) Сумма в долларах запроса транзакции. Этот столбец может предоставлять клиенту возможность выполнять SQL-запросы для вычисления суммы в долларах

Со ссылкой на фиг. 3, проиллюстрированы примерные и неограничивающие роли и операции моста 30. Фиг. 3 изображает различные ходы транзакции и излагает действия моста относительно других действующих сторон транзакции. Транзакции могут возникать в клиенте 310, который может содержать POS 311 и/или компьютерный сетевой узел 312. POS 311 может инициировать транзакцию, которая может проходить через компьютерный сетевой узел 310 в мост 320. Транзакция может продолжать идти через мост 320 и доставляться в процессор 330 карточек с хранимой суммой. Процессор 330 карточек с хранимой суммой затем может заниматься транзакцией (например, посредством обмена информацией с поставщиком 340 услуг) и может возвращать ответ транзакции обратно через мост 320, обратно через компьютерный сетевой узел 312 и в POS 311. В каждом из ходов, мост 320 может не добавлять значение в транзакцию, иное чем для точного соотнесения запроса и связанного ответа.

Точнее, на 350, может быть виден ход транзакции с одобрением, где транзакция была одобрена процессором карточек с хранимой суммой или конечным поставщиком услуг. Этот ход транзакции может возникать в POS 311, проходить через компьютерный сетевой узел 312 и мост 320 в процессор 330 карточек с хранимой суммой. Процессор 330 карточек с хранимой суммой может выдавать код ответа (RC) со значением 00. Мост 320 затем может передавать этот RC в POS 311 через компьютерный сетевой узел 312.

На 360, проиллюстрирована транзакция с жестким отклонением. Вновь, этот ход транзакции может возникать в POS 311, проходить через компьютерный сетевой узел 312 и мост 320 в процессор 330 карточек с хранимой суммой. Процессор 330 карточек с хранимой суммой может выдавать код ответа (RC) со значением 14. Мост 320 затем может передавать этот RC в POS 311 через компьютерный сетевой узел 312.

На 370, проиллюстрировано мягкое отклонение на транзакции с кодом обработки не в 'retry list'. Вновь, этот ход транзакции может возникать в POS 311, проходить через компьютерный сетевой узел 312 и мост 320 в процессор 330 карточек с хранимой суммой. Процессор 330 карточек с хранимой суммой может выдавать код ответа (RC) со значением 96. Мост 320 затем может передавать этот RC в POS 311 через компьютерный сетевой узел 312.

Со ссылкой на фиг. 4, проиллюстрирован примерный ход 40 транзакции при мягком отклонении с замещающим одобрением (SAF=00). Вообще, транзакция может быть «мягко отклонена» процессором карточек с хранимой суммой, и транзакция сконфигурирована в списке 'retry-transaction-code'. Соответственно, мост может помещать проводку в свою очередь SAF и изменяет RC клиенту, чтобы отражал сообщение 'B0'-замещающее одобрение при отклонении. Впоследствии и асинхронно относительно транзакции, мост может отправлять подвергнутый SAF запрос проводки в процессор карточек с хранимой суммой. Первые попытки могут быть отклонены - с RC со значением 96. Однако, так как диспетчер транзакций SAF может придерживаться таких же правил конфигурации, как основной диспетчер транзакций (реального времени), каждый ответ с «мягким отклонением» может приводить к еще одной попытке - по меньшей мере вплоть до сконфигурированного максимального количества попыток или выделенного времени. Когда транзакция преуспевает (то есть, одобрена средством авторизации или процессором карточек с хранимой суммой), проводка может быть маркирована 'TAKEN' и может быть удалена из рассмотрения касательно будущих действий выгрузки SAF.

С продолжающейся ссылкой на фиг. 4, графически проиллюстрирован пример, приведенный выше. Транзакция может возникать в клиенте 410. Клиентский POS 411 может отправлять запрос 450 транзакции через свой компьютерный сетевой узел 412 и в мост 420. Как и раньше, мост 420 может пытаться отправить транзакцию в процессор 430 карточек с хранимой суммой. Если мост 420 принимает мягкое отклонение - RC со значением 96, проиллюстрированное под номером 451 ссылки, мост 420 может устанавливать состояние проводки в 'RETRY', устанавливать RC в B0 на 459, и побуждать POS 411 обращать внимание покупателя, что «Этот продукт будет доступен для использования в течение двадцати четырех (24) часов».

Транзакция затем может направляться в очередь 470 SAF в мосте 420. На 453, транзакция может предприниматься еще раз, хотя код RC со значением 96 проиллюстрирован на 454, отмечая дополнительное мягкое отклонение. Транзакция может отмечаться как 'RETRY' на 455. На 456 может предприниматься вновь, и снова может получать код RC со значением 96 на 457. Вновь, транзакция может отмечаться как 'RETRY' на 458. На 459, транзакция может предприниматься вновь и может успешно проводиться. Код RC со значением 00 может быть возвращен на 460, после чего транзакция может быть помечена флажковым признаком как 'TAKEN' и удалена из очереди SAF.

Со ссылкой на фиг. 5, проиллюстрирован примерный сценарий 50 мягкого отклонения с замещающим одобрением, и SAF=жесткому отклонению. Вообще, транзакция может быть мягко отклонена процессором карточек с хранимой суммой или конечным поставщиком услуг, и транзакция снова может быть сконфигурирована в списке 'retry-transaction-code'. Соответственно, мост может обеспечивать замещающее одобрение при отклонении, и может помещать проводку в очередь SAF, и сообщать код RC в POS со значением B0. Впоследствии и возможно асинхронно, мост может отправлять подвергнутый SAF запрос проводки в процессор карточек с хранимой суммой. Две попытки авторизовать проводку могут получать дополнительные мягкие отклонения. Третья попытка может принимать жесткое отклонение из процессора карточек с хранимой суммой. Эта проводка затем удаляется из очереди SAF и должна быть включена в файл исключений.

С продолжающейся ссылкой на фиг. 5, графически проиллюстрирован пример, приведенный выше. Транзакция может возникать в клиенте 510. Клиентский POS 511 может отправлять запрос 550 транзакции через свой компьютерный сетевой узел 512 и в мост 520. Как и раньше, мост 520 может пытаться отправить транзакцию в процессор 530 карточек с хранимой суммой. Если мост 520 принимает мягкое отклонение - RC со значением 96, проиллюстрированное под номером 551 ссылки, мост 520 может устанавливать состояние проводки в 'RETRY', устанавливать RC в B0 на 559, и побуждать POS 411 обращать внимание покупателя, что «Этот продукт будет доступен для использования в течение двадцати четырех (24) часов».

Транзакция затем может направляться в очередь 570 SAF в мосте 520. На 554, транзакция может предприниматься еще раз, хотя код RC со значением 96 проиллюстрирован на 555, отмечая дополнительное мягкое отклонение. Транзакция может отмечаться как 'RETRY' на 556. На 557, транзакция может предприниматься вновь, и снова может получать код RC со значением 96 на 558. Вновь, транзакция может отмечаться как 'RETRY' на 559. На 560, транзакция может предприниматься вновь, и может получать код RC жесткого отклонения со значением 14, проиллюстрированный под номером 561 ссылки. На 562 проводка может помечаться флажковым признаком в качестве 'TAKEN' и удаляться из очереди 570 SAF. Вследствие жесткого отклонения из процессора 530 карточек с хранимой суммой, проводка должна быть включена в файл исключений.

Со ссылкой на фиг. 6, проиллюстрирован примерный сценарий 60 мягкого отклонения с замещающим одобрением моста, где SAF достигает максимального количества попыток. Вообще, транзакция может быть мягко отклонена процессором карточек с хранимой суммой или конечным поставщиком услуг, но транзакция может быть сконфигурирована в списке 'retry-transaction-code'. Мост затем может помещать проводку в очередь SAF и может выдавать замещающее одобрение, тем самым, меняя RC на 'B0'. Впоследствии и возможно асинхронно, мост может отправлять подвергнутый SAF запрос проводки в процессор карточек с хранимой суммой. В этом примере, мост может быть не успешен в получении одобрения или жесткого отклонения и, взамен, может достигать максимального количества попыток. В итоге, диспетчер SAF может распознавать, что было удовлетворено пороговое значение 'max-transmissions'. Прежде любой успешной попытки, диспетчер SAF может маркировать проводку в качестве 'MAX' и убирать ее из рассмотрения касательно будущих действий выгрузки SAF. Эта проводка также может быть включена в файл исключений.

С продолжающейся ссылкой на фиг. 6, графически проиллюстрирован пример, приведенный выше. Транзакция может возникать в клиенте 610. Клиентский POS 611 может отправлять запрос 650 транзакции через свой компьютерный сетевой узел 612 и в мост 620. Как и раньше, мост 620 может пытаться отправить транзакцию в процессор 630 карточек с хранимой суммой. Если мост 620 принимает мягкое отклонение - RC со значением 96, проиллюстрированное под номером 651 ссылки, мост 620 может устанавливать состояние проводки в 'RETRY' на 652, устанавливать RC в B0 на 653, и побуждать POS 611 обращать внимание покупателя, что «Этот продукт будет доступен для использования в течение двадцати четырех (24) часов».

Транзакция затем может направляться в очередь 670 SAF в мосте 620. На 654, транзакция может предприниматься еще раз, хотя код RC со значением 96 проиллюстрирован на 655, отмечая дополнительное мягкое отклонение. Транзакция может отмечаться как 'RETRY' на 656. На 657, транзакция может предприниматься вновь, и снова может получать код RC со значением 96 на 658. Вновь, транзакция может отмечаться как 'RETRY' на 659. На 660, транзакция может достигать максимального допустимого количества попыток и может помечаться флажковым признаком 'MAX' на 661. В этот момент, диспетчер SAF может удалять проводку из очереди. Отметим, что вследствие достижения максимального количества попыток без окончательного одобрения или отклонения из процессора 630 карточек с хранимой суммой, проводка должна быть включена в файл исключений.

Со ссылкой на фиг. 7, проиллюстрирован примерный сценарий 70 превышения лимита времени компьютерным сетевым узлом с замещающим одобрением. Вообще, две ситуации превышения лимита времени показаны для иллюстрации, когда действие предпринимается мостом. В первом случае, код обработки не находится в списке 'retry'; во втором случае, код обработки находится в списке 'retry'. В первом случае, может быть принято отклонение, с кодом RC со значением 'D2' (отклонение при превышении лимита времени запрашиваемого удаленного компьютерного сетевого узла). Запрос обращения хода может создаваться и отправляться в SAF для отправки в процессор карточек с хранимой суммой. Во втором случае, мост может превышать лимит времени запроса, но может регистрировать замещающее одобрение, где код RC имеет значение 'B1'. Подвергнутый SAF запрос может отправляться в процессор карточек с хранимой суммой до тех пор, пока он не допущен или не одобрен процессором карточек с хранимой суммой - в какой момент, проводка может помечаться флажковым признаком 'TAKEN' и убираться из рассмотрения касательно будущих действий выгрузки SAF.

С продолжающейся ссылкой на фиг. 7, графически проиллюстрирован пример, приведенный выше. Транзакция может возникать в клиенте 710. Клиентский POS 711 может отправлять запрос 750 транзакции через свой компьютерный сетевой узел 712 и в мост 720. Как и раньше, мост 720 может пытаться отправить транзакцию в процессор 730 карточек с хранимой суммой. Если мост 720 превышает лимит времени на 751, состояние может быть установлено в 'RETRY', а обращение хода установлено в 'TRUE' на 752. Мост затем может передавать RC со значением 'D2' на 753, информируя POS 711, что следует «попробовать еще раз прямо сейчас».

Однако, на 754, превышение лимита времени компьютерным сетевым узлом может получать иной результат. Здесь, может происходить превышение 755 лимита времени, и состояние снова может устанавливаться в 'RETRY,' но обращение хода устанавливаться в 'FALSE' на 756. На 757, RC со значением B1 может отправляться в POS, чтобы информировать покупателя, что «этот продукт будет доступен для использования в течение двадцати четырех (24) часов». На 758, очередь 770 SAF может пытаться провести транзакцию снова и вновь может превышать лимит времени на 759. На 760, проводка вновь может помечаться флажковым признаком в качестве 'RETRY'. На 761, мост снова может пытаться провести транзакцию, и, в это время, может принимать мягкое отклонение из процессора карточек с хранимой суммой с кодом RC со значением 96 на 762. Вновь, проводка может помечаться флажковым признаком как 'RETRY' на 763. В заключение, на 764, транзакция может проводиться, и может возвращаться код RC со значением 00, указывающий, что транзакция была успешна. На 766 проводка может помечаться флажковым признаком в качестве 'TAKEN' для удаления ее из очереди 770 SAF.

Со ссылкой на фиг. 8, проиллюстрирован примерный сценарий превышения лимита времени компьютерным сетевым узлом с замещающим одобрением мостом, где достигается максимальное количество попыток. Вообще, запрос транзакции может отправляться в мост из POS, и запрос может превышать лимит времени. Мост затем может помещать проводку в свою очередь SAF, выдавать замещающее одобрение и сообщать обратно в POS код RC со значением 'B1'. Затем, мост может отправлять подвергнутый SAF запрос проводки в процессор карточек с хранимой суммой. Первая попытка также может превышать лимит времени; вторая попытка может получать мягкое отклонение. Все последующие попытки могут превышать лимит времени или получать мягкое отклонение. В итоге, диспетчер SAF может распознавать, что период времени между созданием отдельной записи SAF ('safMeta.created') теперь превышает время, заданное в 'expired-after.' Диспетчер затем может маркировать проводку в качестве 'EXP' и убирать ее из рассмотрения касательно дальнейших действий выгрузки SAF. Эта проводка должна быть включена в файл исключений.

С продолжающейся ссылкой на фиг. 8, графически проиллюстрирован пример, приведенный выше. Транзакция может возникать в клиенте 810. Клиентский POS 811 может отправлять запрос 850 транзакции через свой компьютерный сетевой узел 812 и в мост 820. Как и раньше, мост 820 может пытаться отправить транзакцию в процессор 830 карточек с хранимой суммой. Если мост 820 превышает лимит времени, как проиллюстрировано под номером 851 ссылки, мост 820 может устанавливать состояние проводки в 'RETRY' на 852, обращение хода='FALSE' на 852, устанавливать RC в B1 на 853, и побуждать POS 811 обращать внимание покупателя, что «Этот продукт будет доступен для использования в течение двадцати четырех (24) часов».

Транзакция затем может направляться в очередь 870 SAF в мосте 820. На 854, транзакция может предприниматься вновь, однако, она снова может превышать лимит времени на 855. Проводка может помечаться флажковым признаком 'RETRY' на 856. На 857, транзакция может предприниматься вновь, и может получать код RC со значением 96 на 858. Вновь, транзакция может отмечаться как 'RETRY' на 859. На 860, транзакция вновь может превышать лимит времени на 861. Транзакция вновь может помечаться флажковым признаком в качестве 'RETRY' на 862. Однако, время для отдельной записи может распознаваться превышающим величину 'expire-after' и, на 863, проводка может устанавливаться в состояние 'EXP'. В этот момент, диспетчер SAF может удалять проводку из очереди. Отметим, что, вследствие достижения максимального времени без окончательного одобрения или отклонения из процессора 830 карточек с хранимой суммой, проводка должна быть включена в файл исключений.

Со ссылкой на фиг. 8, проиллюстрирован примерный сценарий режима 80 приостановки. Вообще, фиг. 8 иллюстрирует режим приостановки, когда код обработки находится в списке 'RETRY', и когда он там не находится. Когда код обработки не находится в списке 'retry', мост может превышать лимит времени запроса и помещать проводку в очередь SAF, выдавать замещающее одобрение и менять RC, сообщаемый клиенту, на 'B1'. Мост может превышать лимит времени количество раз - превышающее значение 'max-timeouts', заданное в диспетчере эхо-сообщений, что может устанавливать мост в режим 'suspend' ('приостановки').

В то время как в режиме приостановки, мост может принимать решение по транзакциям локально, не требуя внешнего средства авторизации. Если задано в 'retry-transaction-code,' мост может помещать проводки в очередь SAF и менять код ответа перед возвратом транзакции в POS. Код ответа может быть изменен на 'B3' (замещающее одобрение при приостановке моста) или 'D3' (отклонение при приостановке моста). Отметим, что мост не будет пытаться выгружать отдельные записи SAF до тех пор, пока не изменен режим приостановки. Если процессор карточек с хранимой суммой отвечает на «эхо»-запрос, мост будет выходить из режима приостановки, возобновлять выдачу запросов процессору карточек с хранимой суммой касательно запросов транзакции и выгружать очередь SAF с помощью диспетчера SAF.

С продолжающейся ссылкой на фиг. 9, графически проиллюстрирован пример, приведенный выше. Транзакция может возникать в клиенте 910. Клиентский POS 911 может отправлять запрос 950 транзакции через свой компьютерный сетевой узел 912 и в мост 920. Как и раньше, мост 920 может пытаться отправить транзакцию в процессор 930 карточек с хранимой суммой. Если мост 920 превышает лимит времени, как проиллюстрировано под номером 951 ссылки, мост 920 может устанавливать состояние проводки в 'RETRY' на 859, обращение хода='FALSE' на 852, устанавливать RC в B1 на 953, и побуждать POS 911 обращать внимание покупателя, что «Этот продукт будет доступен для использования в течение двадцати четырех (24) часов». Транзакция будет повторяться до тех пор, пока не достигнуто максимальное количество превышений лимита времени на 955, а мост не входит в режим приостановки.

Во время режима приостановки, мост 920 может принимать запросы 954 транзакции из POS 911. Мост 920 может локально авторизовать транзакции, устанавливая состояние в 'RETRY' на 956 и возвращая код ответа со значением 'B3' на 957. Более того, мост 920 будет продолжать отправлять эхо-запросы 958 в процессор 930 карточек с хранимой суммой, хотя эхо-сообщение может превышать лимит времени на 959.

Если код обработки не находится в списке 'retry', транзакция 960 может быть отклонена мостом, и может выдаваться код RC со значением 'D3' (отклонение при приостановке моста). В некоторый момент, эхо-сообщение 962 может возвращаться процессором карточек с хранимой суммой. Мост 920 будет выводить сам себя из режима приостановки, и последующие транзакции - такие как 963, будут пропускаться напрямую в процессор 930 карточек с хранимой суммой и могут получать успешные сообщения с RC со значением '00' на 964, которые мост 920 может передавать в POS 911 на 965. Впоследствии, очередь 970 SAF может выгружаться на 966, принимая коды RC со значением '00' на 967 и помечая проводку флажковым признаком как 'TAKEN' на 968, тем самым, удаляя проводку из очереди SAF.

Со ссылкой на фиг. 10, проиллюстрирован сценарий 1000, включающий в себя основанные на инициаторе лишения силы и обращения хода. Вообще, мост может принимать сообщение класса обращения хода (MTI 0400) с клиентского компьютерного сетевого узла. Этот запрос транзакции может быть основан на (i) аннулировании/лишении силы в POS; (ii) системное превышение лимита времени на POS; или (iii) системное превышение лимита времени на компьютерном сетевом узле. Мост может допускать такие запросы локально и помещать проводки в очередь SAF, и отвечать кодом RC со значением 'B4' (принудительное одобрение/допущенное обращение хода). Впоследствии и возможно асинхронно, мост может отправлять подвергнутый SAF запрос в процессор карточек с хранимой суммой. Если этот повтор достигает успеха, проводка может маркироваться 'TAKEN' и убираться из рассмотрения касательно будущих действий выгрузки SAF.

С продолжающейся ссылкой на фиг. 10, графически проиллюстрирован пример, приведенный выше. Транзакция может возникать в клиенте 1010. Клиентский POS 1011 может отправлять запрос 1050 транзакции через свой компьютерный сетевой узел 1012 и в мост 1020. В отличие от того, что раньше, мост 1020 может не пытаться отправить транзакцию в процессор 1030 карточек с хранимой суммой, но может помечать проводку флажковым признаком 'RETRY' на 1051 и возвращать RC со значением 'B4' на 1052. POS 1011 может принимать этот ответ на 1053. Проводка затем будет выдаваться в очередь 1060 SAF и будет поставляться в процессор 1030 карточек с хранимой суммой на 1054. Если допущена процессором 1030 карточек с хранимой суммой, RC может быть установлен в '00' на 1055, и проводка может помечаться флажковым признаком как 'TAKEN' на 1056, тем самым удаляя ее из очереди SAF.

Отметим, что могут быть сценарии, при которых текущее содержимое таблицы SAF может оказывать влияние на режим обработки транзакций моста. Например, если мост раньше поместил активацию карточки в очередь SAF - но еще не должен успешно доставить проводку - но далее принимает запрос деактивации для той же самой карточки, может быть уместным помещать новую проводку (деактивации) непосредственно в очередь SAF в надлежащем хронологическом порядке. Следующая таблица иллюстрирует, каким образом мост может осуществлять конкретные оценки на основании содержимого ожидающей обработки проводки в таблицах SAF, где «A» - активация, «AR» - обращение хода активации, «D» - деактивация, а «DR» - обращение хода деактивации.

Ситуация Запрос Верхняя запись SAF Ответ 1 A A D1 - Отклонение на ожидающей обработки SAF 2 A AR B2 - замещающее одобрение при ожидающей обработки комплементарной проводке в SAF 3 A D B2 - замещающее одобрение при ожидающей обработки комплементарной проводке в SAF 4 A DR Если верхними 3 отдельными записями SAF являются DR-D-A, то есть условие «Открытая A» (ход 'D' был обращен, оставляя 'A' простаивающей), то: D1 - Отклонение при ожидающем обработки SAF Иначе - B2 - замещающее одобрение при ожидающей обработки комплементарной проводке в SAF 5 D A B2 - замещающее одобрение при ожидающей обработки комплементарной проводке в SAF 6 D AR B2 - замещающее одобрение при ожидающей обработки комплементарной проводке в SAF 7 D D B5 - Дубликатное одобрение 8 D DR B2 - замещающее одобрение при ожидающей обработки комплементарной проводке в SAF

В некоторых случаях, верхние отдельные записи SAF, изображенные выше, могут предполагать, что предыдущие проводки для карточки также были подвергнуты SAF. Например, в случае 3, описанном выше, единственный путь, которым деактивация попадает в очередь SAF, существует, если активация, которая предшествовала, также была помещена в SAF. Поэтому, полной последовательностью для случая 3 должна быть по меньшей мере 'A-D-A'. На практике, эта последовательность событий часто возникает, когда приобретатель карточки - сталкивающийся с чеком, который сообщает «карточка будет активна в течение двадцати четырех (24) часов» - требует, чтобы карточка подвергалась повторной попытке, так как он желает немедленно использовать продукт. Это может ставить продавца на POS в положение необходимости деактивировать и повторно активировать продукт. Однако, до тех пор, пока проводки SAF не были выгружены, результат, представляемый покупателю, может оставаться прежним.

Со ссылкой на фиг. 11, далее будет обсуждена ситуация 1100 с ожидающим обработки SAF. Вообще, эта ситуация может возникать, когда транзакция мягко отклонена процессором карточек с хранимой суммой, и транзакция сконфигурирована в списке 'retry-transaction-code'. Мост может помещать проводку в очередь SAF и менять код RC на B0 (замещающее одобрение при отклонении). Мост может информировать POS, чтобы информировать покупателя, что «этот продукт будет доступен для использования в течение двадцати четырех (24) часов». Однако, мост затем может принимать вторую транзакцию для того же самого продукта. Мост может проверять очередь SAF и определять, что есть ожидающая обработки проводка в очереди SAF. Поэтому, мост может регистрировать отклонение в качестве 'D1', и сообщать об этом обратно. Впоследствии и асинхронно, мост может отправлять подвергнутый SAF запрос проводки в процессор карточек с хранимой суммой.

С продолжающейся ссылкой на фиг. 11, графически проиллюстрирован пример, приведенный выше. Транзакция может возникать в клиенте 1110. Клиентский POS 1111 может отправлять запрос 1150 транзакции через свой компьютерный сетевой узел 1112 и в мост 1120. Как и раньше, мост 1120 может пытаться отправить транзакцию в процессор 1130 карточек с хранимой суммой. Если мост 1120 принимает мягкое отклонение на 1151, он может помечать проводку флажковым признаком как 'RETRY' на 1152, и возвращать код RC в POS в качестве B0 на 1153. На 1154 мост может отправлять проводку в очередь 1170 SAF для более поздней обработки. Если мост затем принимает вторую транзакцию для той же самой карточки на 1155, мост может не пересылать эту транзакцию в процессор 1130 карточек с хранимой суммой, но может выдавать код RC со значением 'D1' - или отклонение - на 1156. Это может выдаваться в POS 1111 на 1157, и может сообщаться «Исходный запрос допущен». В последствии, на 1158, очередь 1170 SAF может отправлять запрос 1158 транзакции в процессор 1130 карточек с хранимой суммой и принимать код RC со значением '00' на 1159, указывающий, что транзакция была допущена. На 1160 проводка может помечаться флажковым признаком в качестве 'TAKEN' и удаляться из очереди 1170 SAF.

Со ссылкой на фиг. 12, далее будут обсуждены некоторые примерные сценарии 1200 комплементарных проводок в SAF. Вообще, транзакция может отправляться в процессор карточек с хранимой суммой, может мягко отклоняться, и транзакция может быть сконфигурирована в списке 'retry-transaction-code'. Мост может помещать проводку в очередь SAF и менять RC, сообщаемый обратно клиенту, на 'B0' (замещающее одобрение при отклонении). Мост затем может принимать второй запрос транзакции для той же самой карточки, на этот раз, деактивации. Мост может проверять очередь SAF и распознавать, что есть ожидающая обработки активация. Мост может помещать проводку в очередь SAF и сообщать код RC со значением 'B2' (замещающее одобрение при ожидающей обработки комплементарной проводке в SAF) обратно клиенту. Мост затем может принимать еще одну деактивацию. Вновь, мост может проверять очередь SAF и определять, что есть ожидающая обработки деактивация в очереди. Соответственно, мост может сообщать обратно код RC со значением 'B5' (дубликатное одобрение). Впоследствии и асинхронно, мост может отправлять подвергнутые SAF запросы двух проводок (активации и первой деактивации) в процессор карточек с хранимой суммой.

С продолжающейся ссылкой на фиг. 12, графически проиллюстрирован пример, приведенный выше. Транзакция может возникать в клиенте 1210. Клиентский POS 1211 может отправлять запрос 1250 транзакции через свой компьютерный сетевой узел 1212 и в мост 1220. Как и раньше, мост 1220 может пытаться отправить транзакцию в процессор 1230 карточек с хранимой суммой. Если мост 1220 принимает мягкое отклонение на 1251, он может помечать проводку флажковым признаком как 'RETRY' на 1252, и возвращать код RC в POS в качестве B0 на 1253. На 1254 мост может отправлять проводку в очередь 1270 SAF для более поздней обработки.

Если мост затем принимает вторую транзакцию для той же самой карточки на 1255, мост может не пересылать эту транзакцию в процессор 1230 карточек с хранимой суммой, но может помечать проводку флажковым признаком как 'RETRY' на 1256 и выдавать код RC со значением 'B2' на 1257. Мост 1220 затем может принимать третий запрос транзакции для той же самой карточки на 1258. Мост 1220 вновь может предотвращать отправку этого запроса в процессор 1230 карточек с хранимой суммой и взамен может возвращать код RC со значением 'B5' на 1259. Впоследствии, на 1260, очередь SAF может отправлять первую проводку на 1260 в процессор 1230 карточек с хранимой суммой и может принимать код RC со значением '00' на 1261, и может метить проводку первой транзакции флажковым признаком в качестве 'TAKEN' на 1262. На 1263, очередь SAF может отправлять вторую проводку транзакции в процессор 1230 карточек с хранимой суммой, который снова может допускать транзакцию и возвращать код RC со значением '00' на 1264. На 1265, вторая проводка также может быть помечена флажковым признаком как 'TAKEN.' Обе проводки могут быть удалены из очереди SAF.

Со ссылкой на фиг. 13, проиллюстрирован примерный сценарий 1300 UPC вне допустимого диапазона минимума - максимума. Вообще, может быть осуществлена попытка повторно загрузить продукт с суммой ниже допустимого минимума или выше допустимого максимума. Транзакция отправлялась бы в процессор карточек с хранимой суммой, который может выдавать мягкое отклонение. Мост затем может проверять сконфигурированный диапазон минимума/максимума для UPC в файле проводок и определять, является ли сумма меньшей или большей, чем предельные значения. Если сумма является меньшей, чем предельные значения, мост может возвращать код RC со значением 'D6' (отклонение при UPC, меньшем, чем определенная минимальная сумма), тогда как, если сумма является большей, чем максимум, мост может возвращать код 'D7' (отклонение при UPC, большем, чем определенная максимальная сумма).

С продолжающейся ссылкой на фиг. 13, графически проиллюстрирован пример, приведенный выше. Транзакция может возникать в клиенте 1310. Клиентский POS 1311 может отправлять запрос 1350 транзакции через свой компьютерный сетевой узел 1312 и в мост 1320. Мост 1320 может пытаться отправить транзакцию в процессор 1330 карточек с хранимой суммой. Если мост 1320 принимает мягкое отклонение на 1351, он может просматривать таблицу 1354 на 1352 максимумов/минимумов UPC и возвращать код RC со значением 'D6' или 'D7' на 1353.

Со ссылкой на фиг. 14, проиллюстрирован примерный сценарий 1400 UPC, не действующего для SAF. Вообще, транзакция может быть мягко отклонена процессором карточек с хранимой суммой, и транзакция может быть сконфигурирована в списке 'retry-transaction-code'. Мост может проверять сконфигурированный диапазон максимума/минимума для файла проводок на UPC, чтобы определять, находится ли запрошенное значение в диапазоне. Мост также может проверять флажковый признак активности в файле проводок для UPC и определять, что он установлен в 'N'. Соответственно, мост может возвращать RC со значением 'D8' (проводка не активна для SAF; замещающее одобрение при мягком отклонении не выполнено).

С продолжающейся ссылкой на фиг. 14, графически проиллюстрирован пример, приведенный выше. Транзакция может возникать в клиенте 1410. Клиентский POS 1411 может отправлять запрос 1450 транзакции через свой компьютерный сетевой узел 1412 и в мост 1420. Мост 1420 может пытаться отправить транзакцию в процессор 1430 карточек с хранимой суммой. Если мост 1420 принимает мягкое отклонение на 1451, он может просматривать таблицу 1452 максимумов/минимумов UPC и возвращать код RC со значением 'D8'.

Протоколирование в журнале

Все действия моста могут регистрироваться в файле журнала регистрации, неформально упоминаемом как журнал регистрации 'Q2'. Поиск и устранение неисправностей и анализ событий типично могут начинаться исследованием этих файлов. Такие файлы также могут содействовать пониманию читающего, как работает мост. Журналы регистрации могут управляться службой ротации журналов регистрации - где каждый журнал регистрации поддерживается в поддающемся управлению размере (например, не большем, чем 100 Мбайт).

Отдельные записи в журналах регистрации могут показывать список развертывания (во время запуска) и свертывания (во время останова) всех прикладных компонентов. Журналы регистрации могут исследоваться в качестве части обычного порядка для подтверждения действительности запуска 'clean' ('очистки'). Это может быть уместным во время процесса добавления новых признаков и функций в приложение.

Что касается ('нормальной') транзакции 'normal', регистрация в журнале может давать в результате четыре (4) отдельных записи: (i) входящий запрос (из клиентского компьютерного сетевого узла); (ii) исходящий запрос (во внешнее средство авторизации); (iii) входящий ответ (из внешнего средства авторизации); и/или (iv) исходящий ответ (обратно в клиентский компьютерный сетевой узел). В соответствии с некоторыми вариантами осуществления, для того чтобы экономить пространство и уменьшать непроизводительные издержки на обработку, только определенные уместные поля запроса и ответа по ISO8583 (например, PC/3, STAN/11, RRN/37, RC/39) могут отображаться в журналах регистрации.

Если транзакция подвергается SAF, или если происходит какое-нибудь последующее действие, при котором содержимое SAF обновляется, такая информация может передаваться в одноранговый узел, так чтобы содержимое SAF обоих узлов оставалось синхронным. При ('нормальной') попытке 'normal' репликации, это протоколирование в журнале может давать в результате две отдельных записи: исходящий запрос (в одноранговый узел) и входящий ответ (из однорангового узла). Отдельная запись может представлять собой запрос репликации оригинала, то есть, когда проводка сначала помещена в SAF в узле, который обрабатывал запрос.

В дополнение, попытки SAF в отношении внешнего средства авторизации также могут протоколироваться в журнале. Это может давать в результате две отдельных записи: исходящий запрос (во внешнее средство авторизации); и входящий ответ (из внешнего средства авторизации). В соответствии с некоторыми вариантами осуществления, исходный STAN может быть заменен уникальным STAN. В дополнение, подвергнутые SAF запросы канального уровня могут различаться (в отличие от запросов реального времени) с помощью обозначения '01' в коде условия POS.

Каждый раз, когда узел выполняет попытку выгрузить запрос SAF, соответствующий одноранговый узел может информироваться. Различные поля запроса репликации в примерных кодах могут включать в себя элементы данных, такие как: (i) 39 - код ответа (поле 39), который возвращается средством авторизации в ответе SAF (становится зарегистрированным в столбце safMeta.lastRRC); (ii) 105 - ID средства авторизации (поле 38), который возвращается средством авторизации (становится зарегистрированным в столбце safMeta.lastAuthid); (iii) 121 - ID Tranlog запроса (используемый одноранговым узлом - вместе со значением узла в поле 123 (смотрите ниже) - для определения местоположения записи в safMeta; в любом узле Pair, узел+tranld - уникальный идентификатор в пределах safMeta); (iv) 122 - состояние запроса (становится зарегистрированным в столбце safMeta.status однорангового узла); (v) 123 - узел запроса (смотрите 121, приведенный выше, в справочной роли); (vi) 125 - обновленный счет попыток, связанный с запросом (становится зарегистрированным в столбце safMeta.attempts однорангового узла); (vii) 126 - время попытки (становится зарегистрированным в столбце safMeta.lastSent однорангового узла); и/или (viii) 127 - последний STAN попытки (становится зарегистрированным в столбце safMeta.lastStan).

Также может поддерживаться сводка основного диспетчера транзакций ('TM'). Например, может регистрироваться сводка информации о транзакции в реальном времени. Такая информация о транзакции может включать в себя, но не в качестве ограничения: (i) исходящий запрос (во внешнее средство авторизации); (ii) исходящий ответ (обратно в клиентский компьютерный сетевой узел); (iii) профайлер (время, потраченное на каждом участнике транзакции); (iv) код удаленного ответа ('RRC'), принятый из внешнего средства авторизации; (v) события, относящиеся к проверке SAF; и/или (vi) если активизирована обработка SAF, запрос репликации отправляется в одноранговый узел.

Сводка попыток SAF может регистрироваться и комплектоваться, в том числе: исходящий запрос (во внешнее средство авторизации); входящий ответ (из внешнего средства авторизации); профайлер (время, потраченное на каждом участнике транзакции); запрос/ответ репликации (в/из однорангового узла); и состояние репликации.

На одноранговом узле, запись всех действий SAF, сформированных в инициирующем узле, также может протоколироваться в журнале. Это может успешно выполняться посредством 'replication request'. TM репликаций может обрабатывать запросы репликации, происходящие из возможных точек создания в инициирующем узле, в том числе, но не в качестве ограничения: (i) Основной TM - может формировать запросы 'original' ('оригинала') (в одноранговый узел) во время обработки транзакции в реальном времени для проводок, которые попадают в SAF; (ii) TM SAF - может формировать запросы 'update' ('обновления') в одноранговый узел во время последующих выгрузок SAF; (iii) TM синхронизации - может формировать одноранговые запросы 'original' или 'update', когда инициирующий узел синхронизирует одноранговый узел (после перерыва в работе - или отсутствия передачи из - однорангового узла); и/или (iv) TM повторов - может формировать одноранговые запросы 'original', если первый запрос из основного TM претерпел неудачу, или может формировать одноранговые запросы 'update', если одноранговый запрос 'update' из TM SAF или TM синхронизации претерпел неудачу.

Запрос может быть 'original' ('оригиналом') (то есть, полной отдельной записью SAF) или 'update' ('обновлением') (то есть, изменением состояния или другой информацией касательно отдельной записи, которую инициирующий узел знает, что уже зарегистрировал одноранговый узел). Логика репликации может проводить различие 'original' от 'update' с помощью поля 3 по ISO. Если присутствует, запрос может обрабатываться в качестве 'original'; если отсутствует, запрос может обрабатываться в качестве 'update.'

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

Более того, фильтрация может применяться внутри журналов регистрации. Наличие метки или маркера '##' может предоставлять читающему возможность применять фильтр к журналу регистрации, для того чтобы строить сводку событий, связанных с принятием решений SAF, событиями SAF и управлением состоянием HA.

Вспомогательные функции

Клиент моста может предпочесть импортировать 'item file', который может служить для модификации правил замещающего одобрения. Файл может быть построен в формате разделенных запятыми значений ('CSV'), как изложено ниже (одна запись на каждую проводку):

Поле Тип данных Длина Описание/использование UPC AN Постоянная, 12 UPC продукта - это значение фигурирует в поле 53 запроса активации по ISO 8583. Это поле требуется, если задействовано подтверждение действительности UPC (рекомендованная практика). Минимальная сумма N Переменная, 8 Минимальная допустимая сумма активации для продукта. Максимальная сумма N Переменная, 8 Максимальная допустимая сумма активации из продукта. Флажковый признак SAF AN Постоянная, 1 Пригоден ли продукт для замещающего одобрения и SAF ('Y') или нет ('N').

Клиент моста может инициировать обработку импорта файла проводок посредством передачи по протоколу FTP полного файла. Например, файл может быть установлен в: Bridge/spool/item_file/request (также известном как подкаталог 'request'). Соглашение об именах файлов остается за инициатором, но как правило должно иметь расширение '.csv' или '.txt'. Любой файл, не имеющий одного из этих расширений, может быть проигнорирован. Периодически - например, каждые 60 секунд - приложение моста может проверять наличие нового файла импорта с использованием службы опроса каталогов ('DirPoll'). Когда найден надлежащим образом именованный файл, мост может перемещать его из подкаталога 'request' в подкаталог 'run' для обработки. Во время обработки импорта, мост может использовать вход файла проводок для построения эквивалента таблицы базы данных для последующего использования машиной обработки транзакций моста.

После успешного выполнения импорта, мост может выпускать отчет, обобщающий его действия. Эти отчеты могут помещаться в подкаталоге 'response'. По приему любого неправильно сформированного входного файла или при любом событии, побуждающем обработку выполняться до меньшего, чем нормального завершения, мост может перемещать копию входного файла в подкаталог 'bad'. Иначе, мост может перемещать файлы, обработанные до надлежащего завершения, в подкаталог 'archive'.

Машина интерактивной обработки транзакций ('OLTP') моста может использовать получающееся в результате содержимое файла проводок следующим образом. Прежде всего, мост может определять, является ли транзакция допускающей SAF, для замещающего одобрения, так как справедливо одно из следующих условий: (i) узел в настоящее время находится в режиме 'Suspend Mode'; (ii) есть одна или более недоставленных комплементарных проводок в SAF для одной и той же карточки; (iii) запрос превысил лимит времени, и PC находится в списке повторных; или (iv) запрос принял мягкое отклонение (согласно списку 'retry-rc'), и PC находится в списке 'retry-pc'

Затем, если справедливо одно из условий, заданных в (a), мост может осуществлять контроль, чтобы выяснить, находится ли UPC транзакции (поле 54 по ISO 8583) в таблице проводок и - если так - задан ли он в качестве допускающей SAF проводки. На основании файла проводок, мост может отменять предыдущее решение в отношении SAF, как изложено ниже:

Предыдущее решение моста
('SAF') Условие Новое решение моста
('Отмена SAF') B0 - STANDIN_APPROVAL_ON_DECLINE Не в файле проводок ИЛИ
В файле проводок в виде SAF=N D8 - APPLERR_ITEM_INACT_DECLINE B1 - STANDIN_APPROVAL_ON_TIMEOUT Не в файле проводок ИЛИ
В файле проводок в виде SAF=N D9 - APPLERR_ITEM_INACT_TIMEOUT B2 - STANDIN_APPROVAL_ON_IN_SAF Не в файле проводок ИЛИ
В файле проводок в виде SAF=N D8 - APPLERR_ITEM_INACT_DECLINE B3 - STANDIN_APPROVAL_ON_SUSPEND Не в файле проводок ИЛИ
В файле проводок в виде SAF=N D8 - APPLERR_ITEM_INACT_DECLINE Любое из B0-B3 В файле проводок в виде SAF=Y И
Сумма <SAF Min для проводки D6 - APPLERR_ITEM_LESS Любое из B0-B3 В файле проводок в виде SAF=Y И сумма > SAF Max для проводки D7 - APPLERR_ITEM_MORE

Обработка файла исключений

Мост может создавать содержимое файла исключений для отправки в процессор карточек с хранимой суммой. Эти файлы может быть запланировано создавать и доставлять несколько раз в сутки. Мост может размещать проводку в файле исключений, если справедливо одно из следующих условий проводки в файле SAF: (i) проводка утратила силу (safMeta.status - 'EXP'); (ii) проводка достигла своего максимального количества попыток (safMeta.status - 'MAZ'); или (iii) проводка была жестко отклонена средством авторизации (safMeta.status - 'TAKEN', и lastRRC <> '00'). Файл исключений может быть построен в ограниченном программным каналом формате и, в соответствии с некоторыми вариантами осуществления, требуются заголовок и концевик. Пустой файл обозначен заголовком и концевиком без детализирующих записей. Однако, отметим, что предполагается, что пустые файлы по-прежнему могут отправляться в процессор карточек с хранимой суммой.

Поле Тип данных Длина Описание/использование Тип AN Постоянная, 6 'RT0100' Дата/время создания N Постоянная, 14 YYYYMMDDHHMMSS

Детальная запись

Поле Тип данных Длина Описание/использование Тип AN Постоянная, 6 'RT0200' Дата/время транзакции AN Постоянная, 17 Элемент данных ('DE') 13 & 12 по ISO 8583 - в формате, подобном '2013061912:35:58' ID магазина AN Переменная, 15 DE 42 по ISO 8583 вне safData.secureData ID оконечного устройства AN Переменная, 8 DE 41 по ISO 8583 вне safData.secureData Номер карточки N Переменная, 47 DE 2 по ISO 8583 вне safData.secureData Знак N Постоянная, 1 '1'; Act/Reload/Rev of Deact; - 1: Deact/Rev of Act/Rev. of Reload) where Act=189090, Deact=289090, Reload=199090 - saMeta.pc+safData.reversal Сумма на карточке N Переменная, 12 DE4 по ISO8583 вне safData.secureData или safData.amount Сумма скидки N Переменная, 12 Не используется, левый пробел в файле Чистая сумма N Переменная, 12 Не используется, левый пробел в файле UPC AN Постоянная, 12 DE54 по ISO8583 вне safData.secureData Валюта AN Постоянная, 3 DE 49 по ISO 8583 вне safData.secureData STAN N Постоянная, 12 Уникальный порядковый номер операции в платежной системе ('STAN', DE 11 по ISO8583), предоставленный мостом в последнем запросе SAF (сохраненный в safMeta.lastSTAN) ID прослеживания N Постоянная, 20 Код авторизации, предоставленный процессором карточек с хранимой суммой в последнем ответе SAF (сохраненный в safMeta.lastAuthId) Данные активации AN Переменная, 37 DE 35 по ISO8583 вне safData.secureData (если присутствует - может требоваться для разрешения определенных продуктов)

Заключительная запись

Поле Тип данных Длина Описание/использование Тип AN Постоянная, 6 'RT0300' Описатель конца AN Постоянная, 3 'END'

Отметим, что, если мост создает файл исключений, имя файла может включать в себя метку времени из системы в исходный момент создания файла и также может отражать ID (идентификатор) рабочего прогона с исключительной ситуацией, в котором был создан файл.

Мост может доставлять файлы с использованием службы FTP, которая может приводиться в действие периодически. Мост может выполнять запись в таблице saf.Meta (в столбце extractId) в отношении того, была ли отдельная запись SAF включена в файл исключений, и если так, то какая. Таблица, приведенная ниже, иллюстрирует примерные отдельные записи и смысловые значения в таблице.

Описание значения Пример значения Описание/использование <1000000 566 Проводка является исключением, так как ее окончательное состояние имеет значение 'EXP', 'MAX' или 'TAKEN' с safMeta.lastRRC <> '00';
Проводка может быть включена в файл исключений, так как задание извлечения в узле может быть сконфигурировано в виде <property name="create-output-file" value="true"/>; или
Записанное значение может быть текущей итерацией извлечения. В этом примере, это 566^ой раз, когда была выполнена программа извлечения. >1000000 1000566 Проводка является исключением, так как ее окончательное состояние имеет значение (i)-(iii), приведенных выше. Проводка не была включена в файл исключений, так как задание извлечения в узле сконфигурировано как <property name="create-output-file" value="false"/>. Записанное значение является текущей итерацией извлечения+1000000 для обозначения, что выходной файл не был создан. <-1000000 -1000567 Проводка не является исключением, так как ее окончательное состояние имеет значение 'TAKEN' с safMeta.lasRRC='00'
Проводка не была включена в файл исключений, так как не является исключением 0 0 Проводка еще не была охарактеризована, так как (i) проводка все еще активно обрабатывается (состояние имеет значение 'RETRY' или 'PEND'); либо (ii) проводка достигла конечного состояния, но применимое извлечение еще не было осуществлено.

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

Изобретение относится к устройству и способу локальной авторизации транзакций по карточке с хранимой суммой. Технический результат заключается в повышении надежности проведения локальных авторизаций транзакций. Устройство содержит интерфейс POS или компьютерного сетевого узла, обеспечивающий возможность избирательной связи с POS или компьютерным сетевым узлом; интерфейс процессора карточек с хранимой суммой, обеспечивающий возможность избирательной связи с процессором карточек с хранимой суммой; и модуль обработки, обеспечивающий возможность избирательного принятия решения касаемо определенных запросов транзакции по карточке с хранимой суммой, при этом в течение промежутков времени связи с процессором карточек с хранимой суммой модуль обработки не принимает решения касаемо определенных запросов транзакции по карточке с хранимой суммой, но пропускает такие запросы напрямую в процессор карточек с хранимой суммой, и в течение промежутков времени отсутствия связи с процессором карточек с хранимой суммой модуль обработки локально принимает решения касаемо определенных запросов транзакции по карточке с хранимой суммой, при этом транзакциями по карточке с хранимой суммой являются активации, деактивации, повторные загрузки и/или транзакции пополнения. 2 н. и 12 з.п. ф-лы, 14 ил.

1. Устройство для локальной обработки транзакций по карточке с хранимой суммой, причем устройство находится рядом с кассовым терминалом (POS) или компьютерным сетевым узлом розничного торговца, устройство находится на избирательной связи с POS или компьютерным сетевым узлом и процессором карточек с хранимой суммой, при этом устройство содержит:

интерфейс POS или компьютерного сетевого узла, обеспечивающий возможность избирательной связи с POS или компьютерным сетевым узлом;

интерфейс процессора карточек с хранимой суммой, обеспечивающий возможность избирательной связи с процессором карточек с хранимой суммой; и

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

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

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

при этом транзакциями по карточке с хранимой суммой являются активации, деактивации, повторные загрузки и/или транзакции пополнения.

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

3. Устройство по п. 1, в котором в течение промежутков времени связи с процессором карточек с хранимой суммой модуль обработки локально отменяет определенные решения процессора карточек с хранимой суммой на основании ответа, принятого из процессора карточек с хранимой суммой.

4. Устройство по п. 3, в котором процессор карточек с хранимой суммой локально отменяет определенные решения процессора карточек с хранимой суммой, только если тип или номинал карточки с хранимой суммой, тип транзакции и/или сумма транзакции сохранены в качестве приемлемых для отмены.

5. Устройство по п. 4, в котором определенное решение, отмененное модулем обработки, является мягким отклонением.

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

7. Устройство по п. 1, дополнительно содержащее по меньшей мере две (2) базы данных на связи с приложением репликации содержимого для обеспечения резервного хранения.

8. Устройство по п. 1, при этом устройство находится на связи с POS или компьютерным сетевым узлом через один или более балансировщиков нагрузки или мультиплексор.

9. Способ локальной авторизации транзакций по карточке с хранимой суммой, причем способ проводится между кассовым терминалом (POS) или компьютерным сетевым узлом розничного торговца, мостовым процессором и процессором карточек с хранимой суммой, при этом мостовой процессор располагается локально вместе с POS или компьютерным сетевым узлом, причем способ содержит этапы, на которых:

принимают в мостовом процессоре запрос транзакции, при этом запрос транзакции соответствует активации, деактивации, повторной загрузке и/или транзакции пополнения по карточке с хранимой суммой;

определяют посредством мостового процессора, следует ли запрос транзакции пропустить напрямую в процессор карточек с хранимой суммой или принять по нему решение локально;

по определению того, что запрос транзакции следует пропустить напрямую в процессор карточек с хранимой суммой:

передают такой запрос из мостового процессора в процессор карточек с хранимой суммой;

по приему определенного ответа от процессора карточек с хранимой суммой или при неудавшейся связи с процессором карточек с хранимой суммой локально отменяют посредством мостового процессора ответ процессора карточек с хранимой суммой или принимают решение по запросу транзакции локально;

по определению того, что запрос транзакции не следует пропускать напрямую в процессор карточек с хранимой суммой:

посредством мостового процессора локально принимают решение по запросу транзакции;

передают посредством мостового процессора ответ на запрос транзакции обратно в POS или компьютерный сетевой узел; и

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

10. Способ по п. 9, в котором определение посредством мостового процессора, следует ли запрос транзакции пропустить напрямую в процессор карточек с хранимой суммой или принять по нему решение локально, содержит этапы, на которых:

определяют тип транзакции, запрошенной из POS или компьютерного сетевого узла;

определяют, отмечен ли код обработки, связанный с типом транзакции и/или карточкой с хранимой суммой, как приемлемый для локальной обработки; и/или

определяют, находится ли мостовой процессор на связи с процессором карточек с хранимой суммой.

11. Способ по п. 10, в котором, если код обработки, связанный с типом транзакции и/или карточкой с хранимой суммой, не отмечен как приемлемый для локальной обработки, мостовой процессор затем действует в качестве сквозного прохода и пропускает запрос транзакции в процессор карточек с хранимой суммой, а ответ на запрос транзакции обратно в POS или компьютерный сетевой узел.

12. Способ по п. 9, в котором, если мостовой процессор не находится на связи с процессором карточек с хранимой суммой, локально проводят, по меньшей мере, некоторые транзакции в мостовом процессоре до тех пор, пока не будет восстановлена связь с процессором карточек с хранимой суммой.

13. Способ по п. 9, в котором мостовой процессор локально обрабатывает запросы транзакции вслед за превышением лимита времени, принятого от процессора карточек с хранимой суммой.

14. Способ по п. 9, в котором определенным ответом, принятым от процессора карточек с хранимой суммой, который локально отменяется мостовым процессором, является мягкое отклонение.