Проведение платежей

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

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

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

Платёжная форма Payment Page по умолчанию открывается со страницы выбора платёжного метода:

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

Это удобно и помогает улучшать пользовательские сценарии. Однако, стоит учитывать, что при вызове Payment Page с указанием конкретного платёжного метода пользователь оказывается ограничен в выборе иного метода оплаты даже в тех случаях, когда исходная попытка не удалась и могут задействоваться повторные попытки (подробнее). Поэтому открывать Payment Page с указанием метода лучше только когда есть уверенность, что для пользователя актуален выбранный метод оплаты и это сочетается с использованием других возможностей, в том числе для повторных попыток оплаты. Более подробная информация о предварительном выборе платёжных методов представлена в отдельной статье.

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

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

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

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

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

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

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

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

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

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

Информация о требованиях к формату номера телефона в рамках работы с отдельными платёжными методами представлена в разделе Методы.

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

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

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

Выполнение любой финансовой операции подразумевает перемещение средств от определённого „источника“ к заданному „приёмнику“ по связывающему их „каналу“. В случае с платёжной платформой ecommpay это выглядит так:

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

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

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

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

В качестве примера можно рассмотреть ситуацию, когда пользователь из Польши с платёжной картой, счёт которой ведётся в польских злотых (PLN), рассчитывается за определённую услугу в Норвегии с использованием платёжного канала в норвежских кронах (NOK), а балансовой валютой мерчанта при этом выступает евро (EUR). В таком случае конвертация из злотых в кроны выполняется на стороне эмитента (по применяемому им курсу и на его условиях), а конвертация из крон в евро — на стороне ecommpay.

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

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

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

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

• Прежде всего, стоит анализировать свою аудиторию и её платёжные предпочтения. Из каких стран ваши пользователи, какими методами и валютами они предпочитают пользоваться и насколько часто могут сталкиваться с конвертацией.
• Понимая специфику своей аудитории и планы развития бизнеса, стоит настраивать под них спектр используемых платёжных методов и каналов. При этом полезно обращаться к курирующему менеджеру ecommpay для выстраивания оптимальной структуры поддерживаемых валют, балансов и каналов. Помимо прочего, в рамках такой работы могут задаваться валюты, используемые в разных случаях для конвертации по умолчанию, и настраиваться другие полезные решения.
• Работая с широким кругом пользователей, может быть полезным давать им возможность самостоятельного выбора расчётной валюты и избегания конвертации на их стороне (подробнее). При использовании платёжной формы Payment Page такая возможность может обеспечиваться в ней (подробнее). В иных случаях можно настроить это в рамках веб-сервиса.
• Сталкиваясь с другими вопросами и задачами, связанными с конвертацией, также можно обращаться к специалистам ecommpay — мы всегда заинтересованы в том, чтобы обеспечивать лучший сервис для своих клиентов и решать даже самые нетипичные задачи.

Что такое «возврат» в платёжной платформе. Возвратом в рамках платёжной платформы ecommpay называется операция перевода пользователю средств, списанных с него при проведении оплаты. То есть, если что-то в рамках оплаты через платформу с пользователя списали, то посредством возврата через платформу можно это списанное ему вернуть, в рамках той же оплаты.

Довольно просто, но, как водится, есть разные нюансы.

Что стоит знать о возвратах. Чтобы ориентироваться в работе с возвратами, полезно знать о следующем:

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

• Возвраты могут выполняться не во всех случаях.
  Если для оплат с прямым использованием карт возвраты, как правило, доступны без ограничений, то для оплат альтернативными платёжными методами ситуация может быть разной: возвраты могут поддерживаться в полной мере или с ограничениями либо не поддерживаться вовсе. Среди ограничений в таких случаях может быть, например, недоступность частичных возвратов или недоступность любых возвратов по истечении заданного срока давности оплат.
  Что с этим делать? Прежде всего, по каждому из подключаемых альтернативных методов можно уточнять, поддерживаются ли для него возвраты, и если да, то стоит ли учитывать при этом какие-либо особенности. Кроме того, если в каких-то случаях возвраты могут быть недоступны, но вернуть деньги необходимо, можно уточнять, есть ли возможности перевода средств пользователям другими способами (например, посредством выплат через те же или другие платёжные методы). И, как и в иных сложных ситуациях, можно рассчитывать на помощь курирующего менеджера ecommpay.

• Возвраты могут выполняться с помощью разных технических операций.
  С учётом специфики различных платёжных систем технической операцией по возврату средств в разных случаях может выступать reversal или refund. Как правило, reversal используется для возврата, выполняемого до закрытия того операционного дня, в который была проведена соответствующая оплата с использованием платёжной карты, а refund в остальных случаях. Вместе с тем, reversal может использоваться, например в случаях, когда в рамках оплаты с проверкой зачисления (через операцию payment confirmation) выявляется, что средства не были зачислены на счёт.
  Что с этим делать? Иметь в виду, что есть такие нюансы и не удивляться разным названиям операций. К слову, в интерфейсе Dashboard ко всем возвратам применяется название refund (чтобы было немного проще). Если же важно учитывать, в каких случаях была операция reversal, а в каких refund, достаточно контролировать это через программные оповещения и, если актуально, через интерфейс Data API.

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

Как инициировать возвраты. Инициировать возвраты со стороны мерчанта можно через Gate API и Dashboard.

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

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

Можно ли вернуть средства иначе. Безусловно. В каких-то случаях вместо простых оплат с последующими возвратами могут быть полезны оплаты в две стадии. В рамках каждой такой оплаты, как правило, можно сначала блокировать некоторую сумму на счёте пользователя и затем списать только часть этой суммы, сняв блокировку с остатка, или не списывать средства вовсе и вернуть всё пользователю. При этом важным преимуществом может являться скорость возвращения средств: на снятие блокировки могут уходить секунды и минуты, в то время как на возврат средств — часы и дни.

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

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

Введение

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

Условия

• Отмены возвратов и выплат могут выполняться только по тем платёжным методам, для которых поддерживается такая возможность, с учётом возможных дополнительных ограничений по платёжным инструментам и иным критериям.
  Дополнительная информация о таких ограничениях для платежей с прямым использованием платёжных карт представлена в этом ответе. Информацию для альтернативных платёжных методов можно уточнять у специалистов технической поддержки ecommpay.

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

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

• Возвраты могут отменяться только по отдельным операциям refund.
  Операции reversal не подлежат отмене. Также нельзя отменять сразу несколько операций refund с частичными возвратами по одной оплате. Частичные возвраты, как и полные, могут отменяться только по отдельности.

• Возвраты по оплатам с прямым использованием платёжных карт могут отменяться только для карт определённых платёжных систем, с учётом заданных ограничений по времени:
  • для карт American Express — в течение времени, актуального для конкретного проекта (это время можно уточнить через курирующего менеджера ecommpay);
  • для карт Mastercard — в течение 24 часов;
  • для карт Visa — в течение 30 календарных дней.
• Выплаты с прямым использованием платёжных карт могут отменяться только для карт платёжной системы Visa, в течение одного календарного дня и только в исключительных случаях, устанавливаемых и регулируемых платёжной системой.

Порядок действий

Чтобы отменить возврат или выплату, следует:

1. Определить идентификатор отменяемой операции (operation_id) и сообщить о необходимости её отмены специалистам технической поддержки ecommpay.
   Для определения идентификатора при этом можно использовать карточку платежа в интерфейсе Dashboard или программное оповещение о выполнении операции, а для связи с технической поддержкой — интерфейс Dashboard (с функцией Создать обращение в Поддержку в карточке платежа), telegram-бота технической поддержки (с функцией Получить дополнительную информацию у саппорта, доступной по итогам поиска информации о платежах и операциях) или электронную почту (support@ecommpay.com).

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

3. Получить ответ по результатам обработки обращения.
   На обработку подобных обращений, как правило, уходит до получаса, в рамках которых специалисты ecommpay:

   1. Проверяют возможность отмены целевой операции в соответствии с правилами платёжной системы.

   2. Если возможность отмены подтверждена, выполняют необходимые действия.
      При отмене возврата — в рамках платежа, по которому был выполнен возврат, создаётся и выполняется операция refund_reversal, ей присваивается статус success, а платежу — статус partially refunded или success (в зависимости от актуальной суммы платежа); при этом статус отменяемой операции возврата не меняется, а информация о дополнительно созданной операции и обновлении статусов отображается в карточке платежа в интерфейсе Dashboard и не дублируется в программных оповещениях к веб-сервису.
      При отмене выплаты — этой выплате присваивается статус decline; при этом не создаются дополнительные операции, информация о платеже обновляется в интерфейсе Dashboard, а отправка к веб-сервису оповещения с информацией об изменении статуса выплаты выполняется по предварительному согласованию.

   3. Сообщают о результате работ по обращению.

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