Срок действия платежной транзакции

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

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

Чтобы узнать больше о преимуществах использования веб-платежей, ознакомьтесь с расширенными возможностями платежных приложений с помощью веб-платежей .

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

Процесс включает в себя 6 шагов:

  1. Продавец инициирует платежную транзакцию.
  2. Продавец показывает кнопку оплаты.
  3. Клиент нажимает кнопку оплаты.

    Схема сайта сырной лавки с кнопкой BobPay (платежное приложение).

  4. Браузер запускает платежное приложение.

    Схема сайта сырной лавки с приложением BobPay, запущенным в модальном окне. Модальное окно показывает варианты доставки и общую стоимость.

  5. Если покупатель меняет какие-либо данные (например, варианты доставки или свой адрес), продавец обновляет сведения о транзакции, отражающие это изменение.

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

  6. После того как покупатель подтверждает покупку, продавец подтверждает платеж и завершает транзакцию.

    Диаграмма, показывающая, как клиент нажимает кнопку

Шаг 1. Продавец инициирует платежную транзакцию.

Когда покупатель решает совершить покупку, продавец инициирует платежную транзакцию, создавая объект PaymentRequest . Этот объект содержит важную информацию о транзакции:

  • Приемлемые способы оплаты и их данные для обработки транзакции.
  • Подробности, такие как общая стоимость (обязательно) и информация о товарах.
  • Варианты, с помощью которых продавцы могут запрашивать информацию о доставке, например адрес и вариант доставки.
  • Продавцы также могут запросить платежный адрес, имя плательщика, адрес электронной почты и номер телефона.
  • Продавцы также могут указать дополнительный тип доставки ( shipping , delivery или pickup ) в PaymentRequest . Платежное приложение может использовать это как подсказку для отображения правильных меток в своем пользовательском интерфейсе.
const request = new PaymentRequest([{
  supportedMethods: 'https://bobpay.xyz/pay',
  data: {
    transactionId: '****'
  }
}], {
  displayItems: [{
    label: 'Anvil L/S Crew Neck - Grey M x1',
    amount: { currency: 'USD', value: '22.15' }
  }],
  total: {
    label: 'Total due',
    amount: { currency: 'USD', value : '22.15' }
  }
}, {
  requestShipping: true,
  requestBillingAddress: true,
  requestPayerEmail: true,
  requestPayerPhone: true,
  requestPayerName: true,
  shippingType: 'delivery'
});

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

Продавец может передать идентификатор транзакции как часть свойства data объекта PaymentMethodData .

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

Чтобы узнать подробнее, как работает процесс обнаружения, ознакомьтесь с разделом «Настройка способа оплаты» .

Шаг 2. Продавец показывает кнопку оплаты.

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

Используя экземпляр PaymentRequest , продавец может запросить, доступно ли покупателю платежное приложение.

Есть ли у клиента доступное платежное приложение?

Метод canMakePayment() объекта PaymentRequest возвращает true , если платежное приложение доступно на устройстве клиента. «Доступно» означает, что обнаружено платежное приложение, поддерживающее данный способ оплаты, и установлено платежное приложение для конкретной платформы или веб-приложение для оплаты готово к регистрации .

const canMakePayment = await request.canMakePayment();
if (!canMakePayment) {
  // Fallback to other means of payment or hide the button.
}

Шаг 3: Клиент нажимает кнопку оплаты.

Когда покупатель нажимает кнопку оплаты, продавец вызывает метод show() экземпляра PaymentRequest , который немедленно запускает платежный интерфейс.

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

Отсрочка запуска платежного интерфейса

Ознакомьтесь с демонстрацией отсрочки платежного интерфейса до определения окончательной общей стоимости.

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

const getTotalAmount = async () => {
  // Fetch the total amount from the server, etc.
};

try {
  const result = await request.show(getTotalAmount());
  // Process the result…
} catch(e) {
  handleError(e);
}

Если в качестве аргумента show() не указано обещание, браузер немедленно запустит платежный пользовательский интерфейс.

Шаг 4. Браузер запускает платежное приложение.

Браузер может запускать платежное приложение для конкретной платформы или через Интернет. (Вы можете узнать больше о том, как Chrome определяет, какое платежное приложение запускать .)

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

Когда платежное приложение запускается, оно получает информацию о транзакции, переданную объекту PaymentRequest на шаге 1, которая включает в себя следующее:

  • Данные о способе оплаты
  • Общая стоимость
  • Варианты оплаты

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

Шаг 5. Как продавец может обновлять детали транзакции в зависимости от действий клиента

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

Продавец может получать четыре типа событий:

  • Событие изменения способа оплаты
  • Событие изменения адреса доставки
  • Событие изменения варианта доставки
  • Мероприятие проверки продавца

Событие изменения способа оплаты

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

request.addEventListener('paymentmethodchange', e => {
  e.updateWith({
    // Add discount etc.
  });
});

Событие изменения адреса доставки

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

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

request.addEventListener('shippingaddresschange', e => {
  e.updateWith({
    // Update the details
  });
});

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

Событие изменения варианта доставки

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

  • Стандартная доставка - Бесплатно
  • Экспресс-доставка - 5 долларов США.

Когда покупатель обновляет вариант доставки в платежном приложении, продавцу будет отправлено событие 'shippingoptionchange' . Затем продавец может определить стоимость доставки, обновить общую стоимость и вернуть ее в платежное приложение.

request.addEventListener('shippingoptionchange', e => {
  e.updateWith({
    // Update the details
  });
});

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

Мероприятие проверки продавца

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

request.addEventListener('merchantvalidation', e => {
  e.updateWith({
    // Use `e.validateURL` to validate
  });
});

Шаг 6. Продавец подтверждает платеж и завершает транзакцию.

Когда клиент успешно авторизует платеж, метод show() возвращает обещание, которое преобразуется в PaymentResponse . Объект PaymentResponse включает следующую информацию:

  • Детали результата платежа
  • Адрес доставки
  • Вариант доставки
  • Контактная информация

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

Если платежное приложение закрывается из-за сбоя или ошибки платежа, обещание, возвращаемое функцией show() отклоняется, и браузер завершает платежную транзакцию.

Обработка и подтверждение платежа

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

Завершение или повторная попытка транзакции

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

  • Вызовите метод .complete() , чтобы завершить транзакцию и закрыть индикатор загрузки.
  • Позвольте клиенту повторить попытку, вызвав метод retry() .
async function doPaymentRequest() {
  try {
    const request = new PaymentRequest(methodData, details, options);
    const response = await request.show();
    await validateResponse(response);
  } catch (err) {
    // AbortError, SecurityError
    console.error(err);
  }
}

async function validateResponse(response) {
  try {
    const errors = await checkAllValuesAreGood(response);
    if (errors.length) {
      await response.retry(errors);
      return validateResponse(response);
    }
    await response.complete("success");
  } catch (err) {
    // Something went wrong…
    await response.complete("fail");
  }
}
// Must be called as a result of a click
// or some explicit user action.
doPaymentRequest();

Следующие шаги