FAQ

Рис.: Для чего нужен PCI DSS?

Payment Card Industry Data Security Standard (PCI DSS) — это стандарт по надлежащей защите данных о держателях платежных карт. Он разработан Советом по стандартам безопасности индустрии платежных карт и устанавливает требования для всех организаций, применяющих в своей деятельности обработку, хранение или передачу данных платежных карт. Без соблюдения требований PCI DSS проводить платежи с использованием платежных карт нельзя.

Если мерчант обладает сертификатом на соответствие требованиям PCI DSS, он может предоставить Rocketpay копию сертификата и выстраивать работу любым образом, в том числе с хранением данных о картах на своей стороне и передачей этих данных в запросах в явном виде. Если же сертификата нет, необходимо заполнить лист самооценки (с вопросами о его заполнении можно обращаться к курирующему менеджеру Rocketpay), после чего можно хранить данные на стороне платежной платформы и проводить оплаты с помощью платежной формы Rocketpay, а выплаты — с использованием токенов карт (подробнее о токенах — в разделе Использование токенов).

Рис.: В чем различие между тестовой и рабочей средами?

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

Для этого специалисты технической поддержки Rocketpay создают и настраивают в платформе два проекта взаимодействия с подключаемым веб-сервисом — тестовый и рабочий, с отдельным идентификатором для каждого из них. При смене в запросах этого идентификатора (project_id) вы переходите из тестовой среды в рабочую. Поскольку и адреса для приема запросов, и наборы параметров в тестовой и рабочей средах идентичны, важно не путать идентификаторы проектов и обращаться с ними должным образом.

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

Среда — это совокупность внутренних программных компонентов платформы, которые в одном случае сконфигурированы для эмулирования процессов проведения платежей, а в другом — для их реального проведения.

Рис.: Куда отправлять запросы?

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

Это важно учитывать, когда, например, для одних действий используется Payment Page, а для других — Gate. Так, для формирования токена через Payment Page и проведения выплаты по этому токену через Gate потребуются два запроса на два разных адреса: https://paymentpage.rocketpay.kz и https://api.rocketpay.kz. А для получения через Data API информации о балансе средств после проведения этой выплаты — запрос на третий адрес: https://data.rocketpay.kz.

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

• https://api.rocketpay.kz для взаимодействия через Gate. Например, адрес для запроса на получение статуса платежа выглядит как https://api.rocketpay.kz/v2/payment/status. Подробная информация о работе с запросами к Gate API представлена в разделе Запрос.
• https://paymentpage.rocketpay.kz для взаимодействия через Payment Page. Например, GET-запрос на проведение платежа выглядит как GET /payment?payment_currency=EUR&project_id=42&payment_amount=1000&... HTTP/1.1 Host: https://paymentpage.rocketpay.kz. Подробная информация о работе с запросами к Payment Page API представлена в разделе Запрос.
• https://data.rocketpay.kz для взаимодействия через Data API. Например, адрес для запроса на получение балансов выглядит как https://data.rocketpay.kz/balance/get. Подробная информация о работе с запросами к Data API представлена в разделе Использование Data API.
• dashboard.rocketpay.kz для доступа сотрудников мерчантов к веб-интерфейсу Dashboard.

Рис.: В чем различие между платежом и операцией?

Платеж в контексте платформы — некоторая цельная история одного расчета между мерчантом и пользователем. При этом в рамках одного платежа может происходить как однократное движение денежных средств (от пользователя к мерчанту при оплате или в обратную сторону при выплате), так и неоднократное (например, при оплате с последующим возвратом или при серии списаний в рамках одной оплаты). Платеж считается завершенным, когда завершены расчеты между мерчантом и пользователем в рамках оказания соответствующей услуги (и соответствующей исходной заявки мерчанта на проведение платежа). И, как и в жизни, может менять конечное состояние: например, оплата может быть успешно проведенной (success), а спустя некоторое время — частично возвращенной (partially refunded).

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

Для каждого платежа в платформе используется его идентификатор (payment_id), который задается со стороны мерчанта, передается в запросах в платежную платформу и однозначно идентифицирует платеж в рамках проекта. Такие идентификаторы могут состоять из цифр, букв латинского алфавита и других символов в кодировке UTF-8 и не должны превышать 255 знаков: например, payment-123 или cosmoshop.sale_456. При получении корректного запроса в платформе регистрируется платеж и инициируется выполнение операции по этому платежу. Каждой операции в платформе присваивается идентификатор (operation_id), уникальный в рамках платформы. Эти идентификаторы передаются в оповещениях и отображаются в интерфейсе Dashboard.

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

Рис.: В чем различие между оплатой, возвратом и выплатой?

s

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

Проведение оплат возможно через любой из доступных в платежной платформе интерфейсов. Выплаты и возвраты в платежной платформе осуществляются через Gate API и Dashboard.

Рис.: В чем различие между оплатами в одну и две стадии?

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

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

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

При выборе варианта всегда можно обращаться за консультациями к курирующему менеджеру Rocketpay.

Рис.: Почему важно передавать идентификатор и IP-адрес пользователя?

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

Рис.: Как указывать имя пользователя?

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

Для корректного проведения платежей и предотвращения отказов из-за ошибок при указании имен и фамилий важно соблюдать следующие рекомендации:

• имя и фамилия должны быть реальными, например, CARD HOLDER или Customer Name некорректны;
• количество символов в значении отдельного параметра должно быть не менее 2 и, по возможности, не более 50;
• допускается использование букв, цифр и других символов в кодировке UTF-8.

Для параметра card_holder дополнительно к перечисленным применяются следующие ограничения:

• допускается использование букв латинского алфавита без диакритических знаков, букв кириллического алфавита, а также:
  • точки в сокращениях, например в словах Mr. или Jr.;
  • апострофа, например как в d'Arc или O'Hara;
  • дефиса в составных именах и фамилиях, например Anna-Maria или Jean-Baptiste;
• не допускается использование дефиса для сокращений, так как он интерпретируется как разделитель между словами, и поэтому, например, конструкция M-r Holder является некорректной, так как образует три слова, два из которых состоят всего из одной буквы;
• значение должно содержать не менее двух слов и не более одной точки, поэтому, например, конструкция Mr. Alexandre Dumas Jr. является некорректной, а Alexandre Dumas Jr. — допустимой.

Рис.: Как указывать номер телефона?

В связи с тем, что каждый платежный провайдер принимает и обрабатывает номера телефонов по своим правилам, при указании номера телефона в запросе могут возникнуть трудности с заполнением: прописывать ли в начале «+» или «0», указывать ли код страны, использовать ли скобки и дефисы.

Чтобы избежать таких трудностей, в платежной платформе поддерживается обработка телефонных номеров: достаточно отправить номер телефона с кодом страны, и этот номер будет обработан таким образом, чтобы он был принят провайдером, через которого проводится платеж. При этом можно использовать разные форматы, с плюсом, дефисом и другими символами, но все же рекомендуется использовать только цифры (от 4 до 24, без пробелов и знаков препинания: например, 9012345678, 79012345678, 0447307418560, 380671381116, 254712539238), потому что внутри платформы все номера приводятся именно к такому виду.

Если номер должен быть введен пользователем при оплате через Payment Page, пользователю отображается форма с подсказками и защитой от ошибок в формате.

Рис.: Что можно передавать в параметре description?

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

• Если параметр description обязателен, в его значении необходимо указывать причину выполнения операции, например: Частичный возврат оплаты в связи с тем, что пользователь вернул часть заказа (не подошел размер), Полный возврат из-за технических проблем с оказанием услуги или Возврат полной суммы билета из-за отмены сеанса.
• Если параметр description необязателен, в его значении можно указывать любые дополнительные сведения о платеже, например: Пополнение кошелька 007, Зачисление на счет 271828, Оплата по промокоду или Вывод средств по заявке № 314.

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

Рис.: Какие параметры передаются в оповещениях?

В структуру оповещений, отправляемых от платежной платформы Rocketpay к веб-сервису мерчанта, включаются наборы параметров о последней операции и о платеже, к которому она относится. Стандартные параметры для оповещений о проведении финансовых операций и создании токенов описаны в разделе Оповещения (callbacks) в Gate. Вместе с тем, по согласованию со специалистами технической поддержки Rocketpay можно настраивать структуру оповещений с учетом предпочтений мерчанта. Просматривать и изменять настройки оповещений мерчант может только по запросу в техническую поддержку Rocketpay.

Рис.: Почему не приходят оповещения?

Если оповещение не приходит в течение установленного периода времени, убедиться в следующем:

• Ваш веб-сервис ожидает оповещения по URL-адресу, который был передан специалистам Rocketpay при интеграции.
• URL-адрес корректно настроен на прием HTTP-запросов от платежной платформы: IP-адреса Rocketpay добавлены в список разрешенных и сообщения не блокируются брандмауэром или другими сетевыми устройствами.
• В запросе на проведение платежа не передавался параметр callback.force_disable со значением 1, которое запрещает платежной платформе отправлять оповещения по этому платежу.

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

Рис.: Как узнать о статусе платежа или операции?

Для этого можно использовать как пользовательский интерфейс Dashboard, так и программные сообщения — оповещения, отправляемые в заданных случаях, и ответы, отправляемые на запросы о состоянии платежа.

В случаях с программными сообщениями все сводится к таким параметрам, как status, code и message в объектах payment и operation и в массиве errors (подробнее — в разделах Оповещения (callbacks) в Gate и Как узнать статус платежа). При этом информация является актуальной с точностью до скорости формирования и передачи сообщений.

Рис.: Почему в ответе на запрос статус Success, но средства не списаны?

При интеграции c Gate в синхронных ответах на запросы, обрабатываемые по асинхронной схеме, в параметре status в теле ответа указывается статус приема запроса, а не статус платежа или операции. Статус success в теле ответа говорит только о том, что запрос принят в обработку, а статус error указывает, что запрос не принят в обработку и выполняться не будет. Информацию об этих статусах и общей структуре и отправке ответов можно найти в разделе Ответ.

Получать информацию о состоянии платежей и операций, а не о приеме запросов, стоит оперировать параметрами status в соответствующих объектах — payment и operation — в оповещениях и ответах на запросы о состоянии платежей, либо использовать интерфейс Dashboard.

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

Рис.: Как узнать причину отклонения операции?

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

• В синхронном ответе на запрос, если была обнаружена ошибка при первичной обработке запроса. Подробная информация о таких ошибках представлена в разделе Ответ.
• В полученном промежуточном или итоговом асинхронном ответе (оповещении) — через код ответа и сообщение, которые могут быть представлены:
  • в массиве errors, если операция была отклонена на стороне платежной платформы, например, если операция не прошла проверку на соответствие установленным бизнес-правилам;
  • в параметрах operation.code и operation.message, если операция была отклонена на стороне провайдера или платежной системы.
  Подробная информация о работе с оповещениями представлена в разделе Оповещения (callbacks) в Gate.
• В карточке платежа в интерфейсе Dashboard.

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