Далее описывается формат сообщений CyberCash версии 0.8. Предполагается, что читатель знаком с такими терминами как "получатель" (acquirer), "PAN" (первичный номер счета), и т.д., определенными в документе ISO 8583, и назначение валюты (currency designations), как это определено в ISO 4217. Некоторые несущественные поля для упрощения удалены. В последующих примерах сообщений подписи, хэши и шифрованные секции не имеют никакого реального смысла.
4.1. Регистрация персоны и нахождение приложения
Первым шагом, который должен сделать клиент, чтобы использовать CyberCash, является регистрация персоны с помощью своего приложения. Это делается с помощью сообщения R1, описанного ниже. Сервер CyberCash откликается сообщением R2.
Когда приложение покупателя узнает, что оно устарело, оно может воспользоваться запросом GA1, посылаемым серверу, и получить в отклике GA2 подписанную версию самого себя.
4.1.1. R1 – регистрация
Описание: Это исходное сообщение, посылаемое для формирования новой персоны CyberCash.
content-language (язык содержимого) берется из поля заголовка MIME (смотри RFC-1766) и соответствует языку, на котором должно быть написано сообщение (в настоящее время допустимо пока только en-us). swversion используется для проверки, не является ли приложение клиента устаревшим.
4.1.2 R2 – отклик регистрации
Это сообщение предоставляет отклик об успехе или неудаче R1.
swseverity: fatal/warning [отсутствует, если все в порядке]
swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя [присутствует только, если имеется SWSeverity].
message;
Произвольный текст уведомления об успехе или неудаче.
Этот текст должен быть отображен для владельца приложения CyberCash...
В принципе текст включает в себя: duplicate-id (дублированный ID), bad-signature (ошибочная подпись) или ill-formed-registration (некорректная регистрация).
Объяснение:
responseid
применяется для предоставления уникального ID, если в результате ошибки потерян ID, использованный ранее. Если причина неудачи не связана с дублированным ID, это поле может быть опущено.
responseid
предоставляет действительный ID с присоединенными контрольными символами в случае успеха.
swseverity
может предупредить пользователя о том, что приложение устарело или о наличии в нем известных ошибок.
Может не существовать персоны покупателя и поэтому ID может отсутствовать. Может не быть пары ключей покупателя (общедоступный/секретный) и поэтому не быть подписи. swversion является обязательным, так что сервер мог сказать, что следует возвратить.
4.1.4. GA2 – отклик получения приложения (get-application-response)
Возвращает в случае успеха URL копии современного приложения CyberApp или флаг неудачи.
Система CyberCash сконструирована так, чтобы предоставить организации, выпустившей кредитную карту, возможность определить, может ли она использоваться через CyberCash.
Покупатель, после регистрации персоны в CyberCash, как это описано выше, может связать каждую кредитную карту по своему желанию с персоной в системе CyberCash. Это делается с помощью сообщения BC1, посылаемого покупателем своему серверу CyberCash, и отклика BC4, приходящего от сервера.
4.2.1. BC1 – подключение кредитной карты (Bind-Credit-card)
Это начальное сообщение в процессе установления соответствия между кредитной картой и персоной CyberCash.
salt необходимо из- за того, что хэш, запомненный сервером, является менее информативным. Сервер лишь запоминает префикс номера кредитной карты и хэш комбинации номера кредитной карты и salt. Если бы он хэшировал лишь номер кредитной карты, появилась бы возможность выяснить номер кредитной карты путем простого перебора всех возможных номеров. Запись номеров кредитных карт в файлы сервера могут сделать систему весьма уязвимой.
4.2.2. BC4 – отклик подключения кредитной карты (bind-credit-card-response)
Отмечает, что процесс подключения кредитной карты завершился. Присылает флаг успеха или неудачи.
swmessage; message about obsoleteness of customer software to be shown to the customer. [only resent if SWSeverity present]
response-code: success/failure/etc.
card-number: 1234567887654321
card-type: visa
card-salt: 47562310
card-expiration-date: 01/99
card*: [other card* lines to also be given in CH.1 message]
message; Простой текст для пользователя может содержать много строк.
Все строки card* могут быть спасены в виде единого блока для последующего предоставления в CH.1. card-expiration-date, card-number, card-salt и card-type должны присутствовать всегда. В зависимости от причины неудачи не все поля могут быть представлены в сообщении отклике.
4.3. Сообщения покупателя о покупке, содержащие данные о кредитной карте
Вообще, подключение CyberCash к покупке с помощью кредитной карты происходит после того как пользователь определит, что же он, в конце концов, покупает. Когда клиент нажимает клавишу CyberCash “payment”, продавец посылает покупателю сообщение PR1 в виде тела типа MIME риложение/cybercash.
Если покупатель желает продолжить процедуру, он отвечает продавцу сообщением CH1. Продавец реагирует, послав отклик CH2. В паузе между посылкой CH1 и получением CH2, продавец обычно контактирует с сервером CyberCash посредством сообщений CM*.
4.3.1. PR1 – запрос платежа (payment-request)
Это сообщение является первым, которое определено CyberCash в процессе торговой сделки со стороны продавца. Собственно покупка произведена, так как мы собираемся ее оплатить.
Это сообщение подписывается продавцом, но покупатель не может непосредственно проверить эту подпись. Когда платеж произведен, Покупатель подписывает хэш (полученный непосредственно покупателем) платежа. Если соответствия не будет, CyberCash блокирует платежную операцию.
accepts: Программа клиента распознает только одно слово имени карты из поля accepts сообщения PR1. Например,
MasterCard
AmericanExpress
Распознаны как
Master card
American express
Не распознаны. MasterCard и masterCard распознаются оба как master card.
За типом карты следует указатель ключа. Для основного ряда кредитных карт это будет CC*. Клиент может использовать или игнорировать * номер по своему выбору. Для личной карты это будет VK*, где * представляет собой ключ CheckFree, который следует использовать. Карты разделяются запятыми, указатель ключа следует за типом карты и двоеточием.
url-pay-to указывает, куда следует послать CH1.
url-fail и url-success несут информацию о том, где броузер должен искать данные в случае успеха или неудачи.
4.3.2. CH1 – платеж через кредитную карту (credit-card-payment)
Это сообщение осуществляет представление кредитной карты для выполнения платежа. ####################################################################
swmessage; Ujdjhbn CyberApp, что это закрытая часть. Этот текст отображается для пользователя [присутствует только, когда присутствует SWSeverity].
message;
Свободный комментарий причины неудачи или успеха. Этот текст должен быть отображен для покупателя приложением CyberCash.
Закрытая секция является опционной, так как сообщение CH1 продавцу может не пройти, из-за неверного идентификатора заказа (order-id), даты, ошибочного идентификатора продавца (merchant-ccid) и т.д.. Таким образом, сервер не может быть вовлечен, так как в данной ситуации не существует безопасного механизма генерации закрытой секции сообщения.
Если транзакция осуществляет эту процедуру посредством сервера (через CM*), тогда код отклика на верхнем уровне должен быть зеркальным по отношению к коду-отклику сервера, посланного продавцу.
Заметим, что могут быть два сообщения, одно от продавца и одно от сервера.
4.4. Сообщения продавца о покупке, связанные с кредитной картой
Продавец представляет покупки через кредитную карту, делает корректировки и выражает предпочтения через последовательность CM*. Вообще, цикл, сопряженный с кредитной картой включает авторизацию для покупки, включение покупки в перечень на оплату и собственно осуществление оплаты. Имеется возможность удалить определенную позицию из перечня или аннулировать всю сделку (смотри раздел 5.1.). Авторизации всегда осуществляется клиентом через отклики-сообщения CM1 или CM2. Если приобретение выполняется получателем (acquirer) или каким-то другим объектом между сервером CyberCash и получателем, это делается посредством сообщений CM3 или CM2 в зависимости от соглашения между продавцом и объектом, осуществляющим приобретение. Возвраты обрабатываются с помощью сообщений CM5. Сообщение CM4 служит для возврата покупки или возврата до оплаты сделки. CM6 является форматом сообщения, используемого для откликов на все другие CM*-сообщения.
Последовательности MM* были также применены для оплат, осуществляемых продавцом, как описано в разделе 3.4.7
Современные система оплаты предполагают, что продавец знает номер кредитной карточки. Таким образом, чтобы работать с этими системами, предусмотрены специальные обходные сообщения, которые позволяют снабдить продавца нужной информацией, в противном случае CyberCash делает все, чтобы скрыть номер кредитной карты от продавца. Смотри разделы 3.4.8 и 3.4.9. Это делает получение такой информации контролируемым.
Многие современные продавцы работают в режиме "terminal capture", где авторизации получаются продавцом.
4.4.1. CM1 - auth-only (аутентификация)
Это сообщение используется продавцом для выполнения операции авторизации кредитной карты покупателя.
Ключ продавца закрытой части генерируется из общедоступного ключа CyberCash, на который указывает merchant-cyberkey. Закрытую часть сообщения покупателя (Opaque) - смотри CH1.
Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что закрытая часть сообщения покупателя не была повреждена или заменена.
4.4.2. CM2 - auth-capture
Осуществляет авторизацию и вводит сумму оплаты сделки. Сообщение аналогично CM1, хотя и имеет другой код типа.
Подпись продавца гарантирует целостность большей части сообщения. Проверка подписи покупателя гарантирует, что закрытая секция сообщения не была повреждена или заменена.
4.4.4. Сообщение об удалении CM4
Аннулирует возврат денег, если сообщение получено до окончательного расчета. Сообщение аналогично сообщению CM1 за исключением того, что оно имеет другой код типа и снабжено полем номера ссылки возврата (retrieval-reference-number field) (которое включается в подпись).
Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что невидимая часть сообщения клиента не была изменена или замещена.
4.4.5. CM5 - возврат
Возврат полученного ранее платежа. В реальности оплата отрицательной суммы. Сообщение совпадает с CM1 за исключением поля тип.
4.4.6. CM6 – отклик на операцию оплаты (charge-action-response)
Это квитанция, предоставляемая продавцу в качестве уведомления о выполнении платежной операции. Индицирует успех, неудачу или предоставляет какую-то иную информацию.
card-prefix: nnxxxx [ Returned if merchant is not full-PAN]
}
или
{
card-number: 1234567890123456 [Returned if merchant is full-PAN]
}
expiration-date: 12/34 [всегда присутствует]
merchant-swseverity: fatal/warning
merchant-swmessage; Сообщение для продавца об устаревшем номере протокола в стартовой $$-строке сообщения продавца.
merchant-message;
Свободный текст, поясняющий причины неудачи или успеха.
Этот текст направляется сервером продавцу...
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Содержимое скрытой секции (покупателя):
server-date: 19950121100706.nnn
amount: usd 10.00
order-id: 1231-3424-234242
card*: [from successful BC4]
response-code: failure/success/etc.
swseverity: fatal/warning
swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя. [присутствует только, когда имеется SWSeverity]
message;
Свободный текст, поясняющий причины неудачи или успеха. Этот текст следует отобразить покупателю с помощью приложения CyberCash.
retrieval-reference-number
необходимо для аннулирования.
authorization-code
необходим для post-auth-capture. Оба эти поля присутствуют только в сообщении CM6, если оно было присланы банком. Все зависит от выполняемой операции.
card-prefix
(префикс карты) представляет собой первые две и последние четыре цифры номера кредитной карты. По усмотрению банка продавца присылается номер кредитной или ее префикс.
card-hash
является в действительности хэшем всего номера кредитной карты и salt, представленной покупателем. card-hash необходим для того, чтобы продавец мог, если хочет, сортировать транзакции покупателя по его кредитным картам, не зная их номеров.
card*
представляет собой поля card*, полученные вместе с сообщениями CM*, присланными в качестве отклика. Они появляются в алфавитном порядке.
server-date
дублируется в целях безопасности в закрытой секции покупателя.
[]
комментарии, появляющиеся после некоторых полей.
<
/p>
4.4.7. Последовательности сообщений MM*
Последовательности сообщений CM* представляют собой первичную систему покупок с помощью кредитных карт CyberCash для безопасной обработки денежных оплат клиентами системы. Однако продавцы, которые авторизованы их банком для получения оплаты товаров и услуг, могут также получать оплату по телефону, по почте или наличными. Чтобы исключить для продавца необходимость иметь вторую параллельную систему обработки этих платежей, определены последовательности сообщений MM1 - MM6, которые служат для организации таких менее безопасных транзакций. Сообщения MM* очень похожи на последовательность сообщений CM*, но закрытая секция покупателя на самом деле подписана продавцом, при этом не требуется какого-либо дополнительного CyberCash ID покупателя или ссылки на его кредитную карту.
4.4.8. CD1 – запрос данных о кредитной карте
Используется продавцом для получения номера карты и т.д., если нужна информация для разрешения сомнений.
Продавцу может быть нужно знать, какая карта используется, и некоторую другую информацию, для того чтобы разрешить определенные проблемы, возникающие при транзакции.
Вся эта информация содержится в исходном сообщении CH1, вложенном в CM1 для реализации транзакции. Если продавец сохраняет CM1 и другую информацию транзакции, то он может послать это CD1-сообщение серверу.
Пароль является дополнительным уровнем безопасности, он предназначен для ручного ввода со стороны продавца, чтобы авторизовать какую-то необычную операцию. Сервер запоминает хэш CCID продавца и пароля.
4.4.9. CD2 – отклик на данные кредитной карты
Отклик на CD1 с указанием на успешный или нет прием данных о кредитной карте.
merchant-swmessage; Сообщение для продавца о том, что номер информационного протокола в стартовой строке $$ сообщения продавца устарел.
merchant-message;
Свободный текст, поясняющий ошибку или успех операции. Этот текст предназначен сервером для продавца.
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Сообщение в норме возвращает выбранные поля из дешифрованной закрытой части CH1, в том формате, в каком они были посланы серверу в CD1.
4.5. Прикладные сообщения и уведомления об ошибках
Оказалось необходимо ввести в систему CyberCash сообщения номера утилиты, статуса запроса, и специального уведомления об ошибке.
Желательно иметь возможность проверять коннективность, с некоторой точностью синхронизовать часы и определять версии протокола и приложения клиента. Это сделано с помощью сообщения P1, посылаемого клиентом серверу и отклика P2, возвращаемого сервером клиенту.
Клиенты должны быть способны определить состояние предшествующих транзакций, когда клиент или продавец закрэшился во время сессии или произошла потеря информации в ходе или по завершении транзакции. Определены два сообщения-запроса о транзакции TQ1 и TQ2. Один из них осуществляет запрос, а второй аннулирует транзакцию, если она не завершена. Откликом на оба эти запроса является сообщение TQ3, посылаемое сервером.
Так как система работает в режиме запрос-отклик, имеется две ситуации, когда необходимы специальные сообщения об ошибках. Если запрос оказался не интерпретируемым или имеет неизвестный код типа, посылается уведомление об ошибке UNK1. Если отклик оказался не интерпретируемым или имеет неизвестный код типа или имела место какая-то другая ошибка, которая должна быть зафиксирована в журнале событий сервера CyberCash. Клиент или продавец направляют серверу диагностические сообщения DL1 или DL2.
4.5.1.
P1 - ping
Простая проверка доступности сервера со стороны клиента. Здесь для минимизации избыточности не используется никаких криптографических методов.
swversion не включается в P1 по соображениям секретности, по этой причине swseverity и swmessage присутствуют, только если сервер может сказать, что эти вещи устарели.
supported-versions позволяет клиенту знать как можно быстрее, какие версии поддерживаются приложением, а какие нет.
Это попытка клиента аннулировать предыдущую транзакцию или транзакции.>
begin-transaction и end-transaction могут совпадать.
Запрос аннулирования транзакции (TQ.2) определен для взаимодействия клиента с сервером. Этот запрос позволяет клиенту запросить состояние операции и предотвратить операцию, если она еще не осуществлена.
Оплата отчета (Report-fee) представляет собой уведомление о том, что данный отчет имеет цену и его предоставление зависит от оплаты. Транзакции с заданным номером может соответствовать несколько транзакций (аутентификация, оплата и т.д.).
Термины
"исходная транзакция"
относится к платежу или другой транзакции, которая была запрошена или аннулирована. Заметим, что эта транзакция в действительности не является резидентной для сервера.
"request"
относится к запрашивающим сообщениям TQ.2 или TQ.1.
id:
идентификатор сообщения-запроса
date:
дата сообщения-запроса
transaction:
транзакция сообщения-запроса
server-date:
текущая дата/время
type:
Отклик транзакции
response-code:
код отклика для сообщения-запроса, может быть одним из:
"success"
означает, сообщение прошло успешно. Не подразумевает требования присылки состояния запроса.
"failure-hard"
означает, что сообщение-запрос не прошло из-за некорректного формата или по какой-то другой причине.
"failure-swversion"
означает, что запрос не был обработан из-за проблем ревизии программного обеспечения.
message:
сообщение используется только для транзакции TQ, а не к состоянию транзакций, статус или аннулирование которых были запрошены. Сообщение формируется на основании кода отклика:
"success"
сообщение проигнорировано.
"failure-hard"
используется стандартное сообщение уведомление о неудаче.
"failure-swversion"
в случае фатальной ошибки используется стандартное сообщение типа swversion
swseverity:
относится к сообщению-запросу
swmessage:
относится к сообщению-запросу - для полей запрос/отмена ('N' берется из ряда от 1 до N)
transaction-N:
номер исходной транзакции, или, если исходной транзакции на сервере нет, то номер транзакции запроса состояния транзакции с заданным номером. Состояние исходной транзакции может быть одним из:
"success"
исходная транзакция была успешно проведена. Если запросом было сообщение TQ.2, аннулирование не производится.
"failure"
исходная транзакция не была реализована. Если запросом было сообщение TQ.2, аннулирование не производится.
"pending"
исходная транзакция все еще обрабатывается и окончательный результат пока не известен.
"canceled"
исходная транзакция была аннулирована сервером. Последующий приход исходной транзакции не будет обрабатываться, но будет послан отклик "failure-canceled".
server-date-1:
поле server-date из исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.
date-1:
поле даты исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.
type-1:
поле типа исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует.
<
/p>
4.5.6. UNK1 – неизвестная ошибка
Это отклик, который посылается, когда запрос так плох, что вы не можете определить его тип или этот тип не известен. Отклик посылается Продавцом Клиенту или Сервером Продавцу, или Сервером Клиенту.
Текст сообщения о причинах ошибки, которое следует представить пользователю. (Не найден CyberCash-обработчик, проверка целостности обработчика не прошла, специфицирована неизвестная версия протокола, специфицирован неизвестный тип и т.д.)
Это сообщение посылается в качестве отклика, когда не удается найти или понять тип сообщения. Оно всегда имеет в начале поля типа и unknown-error-message. Любые поля запроса, которые удается распознать, копируются с префиксами "x-" в сообщение UNK1, посылаемое в качестве отклика. Таким образом, если появляется x-opaque, это означает, что в исходном запросе было поле opaque и т.д.
Так как покупатель инициирует обмен с продавцом и сервером, а продавец запускает обмен с сервером, это сообщение будет послано только покупателю продавцом или сервером покупателю или продавцу.
Оно должно быть записано для отладочных целей. Вам может быть нужно отслеживать отказы обслуживания посредством сообщений UNK1.
4.5.7. DL1 – диагностическая запись
Клиентская диагностическая запись о плохом сообщении от продавца или сервера.
Приложение клиента не ожидает отклика на это сообщение. Если дешифрация прошла успешно, дешифрованное исходное сообщение будет заключено в закрытую секцию. Если дешифровка не прошла, не дешифрованная закрытая секция берется из исходного сообщения.
4.5.8. DL2 – диагностические журнальные записи продавца (merchant-diagnostic-log)
Диагностическая запись продавца о плохом сообщении от сервера.
Приложение продавца не ждет отклика на это сообщение. Дешифрованное исходное сообщение будет размещено в закрытой части, если только дешифрование произошло успешно. Если шифрование осуществить не удалось, будет послано не дешифрованное сообщение.