Cykl życia transakcji płatności

Dowiedz się, jak sprzedawcy integrują aplikacje płatnicze i jak działają transakcje płatności z interfejsem Payment Request API.

Interfejsy API płatności internetowych to specjalne funkcje płatności wbudowane w przeglądarkę po raz pierwszy. Dzięki płatnościom internetowym integracja sprzedawców z aplikacjami do płatności staje się prostsza, a obsługa klienta jest usprawniona i bezpieczniejsza.

Aby dowiedzieć się więcej o zaletach korzystania z płatności internetowych, zapoznaj się z artykułem na temat upoważniania aplikacji do płatności za pomocą płatności internetowych.

Z tego artykułu dowiesz się, jak przebiega transakcja płatności w witrynie sprzedawcy i jak działa integracja z aplikacją płatniczą.

Proces ten składa się z 6 etapów:

  1. Sprzedawca inicjuje transakcję płatniczą.
  2. Sprzedawca wyświetla przycisk płatności.
  3. Klient naciska przycisk płatności.

    Schemat strony sklepu z serami i przyciskiem BobPay (w aplikacji płatniczej).

  4. Przeglądarka uruchomi aplikację płatniczą.

    Schemat strony sklepu z serami z aplikacją BobPay uruchomioną w oknie modalnym. Okno zawiera opcje dostawy i łączny koszt.

  5. Jeśli klient zmieni jakiekolwiek szczegóły (np. opcje dostawy lub adres), sprzedawca zaktualizuje szczegóły transakcji odzwierciedlające zmianę.

    Schemat pokazujący, jak klient wybiera inną opcję dostawy w oknie aplikacji BobPay. Drugi schemat pokazujący sprzedawcy aktualizowanie łącznego kosztu wyświetlanego w BobPay.

  6. Gdy klient potwierdzi zakup, sprzedawca weryfikuje płatność i finalizuje transakcję.

    Schemat pokazujący, jak klient naciska przycisk

Krok 1. Sprzedawca inicjuje transakcję płatniczą

Gdy klient decyduje się na zakup, sprzedawca inicjuje transakcję płatności, tworząc obiekt PaymentRequest. Ten obiekt zawiera ważne informacje o transakcji:

  • Akceptowane formy płatności i związane z nimi dane podczas przetwarzania transakcji.
  • Szczegóły, takie jak łączna cena (wymagane) i informacje o produktach.
  • Opcje, w których sprzedawcy mogą prosić o informacje o dostawie, takie jak adres i opcja dostawy.
  • Sprzedawcy mogą też poprosić o adres rozliczeniowy, nazwę płatnika, adres e-mail i numer telefonu.
  • Sprzedawcy mogą też uwzględnić opcjonalny typ dostawy (shipping, delivery lub pickup) w atrybucie PaymentRequest. Aplikacja płatnicza może to wykorzystać jako wskazówkę, aby wyświetlać prawidłowe etykiety w swoim interfejsie.
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'
});
Podanie identyfikatora transakcji

Niektóre moduły obsługi płatności mogą wymagać od sprzedawcy podania identyfikatora transakcji wydanego z wyprzedzeniem w ramach informacji o transakcji. Typowa integracja obejmuje komunikację między serwerem sprzedawcy a serwerem modułu obsługi płatności w celu zarezerwowania łącznej ceny. Dzięki temu szkodliwi klienci nie mogą manipulować ceną i oszukiwać sprzedawcy dzięki weryfikacji na końcu transakcji.

Sprzedawca może przekazać identyfikator transakcji w ramach właściwości data obiektu PaymentMethodData.

Po podaniu informacji o transakcji przeglądarka przechodzi proces wykrywania aplikacji do płatności określonych w PaymentRequest na podstawie identyfikatorów formy płatności. Dzięki temu przeglądarka może określić aplikację płatniczą, która ma zostać uruchomiona, gdy tylko sprzedawca będzie gotowy do realizacji transakcji.

Aby dowiedzieć się, jak działa proces wykrywania, przeczytaj artykuł o konfigurowaniu formy płatności.

Krok 2. Sprzedawca wyświetla przycisk płatności

Sprzedawcy mogą obsługiwać wiele form płatności, ale powinni udostępniać przyciski płatności tylko dla tych, z których klient może rzeczywiście korzystać. Wyświetlanie przycisku płatności, którego nie można użyć, nie jest wygodne dla użytkowników. Jeśli sprzedawca może przewidzieć, że forma płatności określona w obiekcie PaymentRequest nie będzie odpowiednia dla klienta, może udostępnić rozwiązanie zastępcze lub w ogóle nie wyświetlać tego przycisku.

Za pomocą instancji PaymentRequest sprzedawca może zapytać, czy klient ma dostępną aplikację płatniczą.

Czy klient ma dostępną aplikację płatniczą?

Metoda canMakePayment() PaymentRequest zwraca true, jeśli aplikacja płatnicza jest dostępna na urządzeniu klienta. Stan „Dostępna” oznacza, że aplikacja płatnicza, która obsługuje daną formę płatności, została wykryta i że aplikacja płatnicza na danej platformie jest zainstalowana lub internetowa aplikacja płatnicza jest gotowa do rejestracji.

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

Krok 3. Klient naciska przycisk płatności

Gdy klient naciśnie przycisk płatności, sprzedawca wywołuje metodę show() w instancji PaymentRequest, która natychmiast uruchamia interfejs płatności.

Jeśli końcowa cena całkowita jest ustawiana dynamicznie (np. pobierana z serwera), sprzedawca może odroczyć uruchomienie interfejsu płatności do czasu, aż łączna kwota będzie znana.

Odroczenie uruchomienia interfejsu płatności

Zapoznaj się z demonstracją odroczenia interfejsu płatności do czasu określenia ostatecznej łącznej ceny.

Aby odroczyć interfejs płatności, sprzedawca przekazuje obietnicę formę show(). W przeglądarce będzie widoczny wskaźnik wczytywania, dopóki nie nastąpi ustępowanie obietnicy, a transakcja będzie gotowa do rozpoczęcia.

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);
}

Jeśli nie ma obietnicy podanej jako argument dla funkcji show(), przeglądarka natychmiast uruchomi interfejs płatności.

Krok 4. Przeglądarka uruchamia aplikację płatniczą

Przeglądarka może uruchamiać aplikację płatniczą na danej platformie lub internetową. Dowiedz się więcej o tym, jak Chrome określa, którą aplikację płatniczą uruchomić.

Sposób tworzenia aplikacji płatniczej zależy w większości od dewelopera, ale zdarzenia wysyłane przez sprzedawcę i do niego, a także struktura danych przekazywanych razem z tymi zdarzeniami są ustandaryzowane.

Gdy aplikacja płatnicza została uruchomiona, otrzymuje informacje o transakcji przekazywane do obiektu PaymentRequest w kroku 1. Obejmują one:

  • Dane formy płatności
  • Łączna cena
  • Opcje płatności

Aplikacja płatnicza wykorzystuje informacje o transakcji do oznaczenia swojego interfejsu użytkownika etykietami.

Krok 5. Jak sprzedawca może zaktualizować szczegóły transakcji w zależności od działań klienta

Klienci mogą zmienić w aplikacji płatniczej szczegóły transakcji, takie jak forma płatności i opcja dostawy. Gdy klient wprowadza zmiany, sprzedawca otrzymuje informacje o zmianie i aktualizuje szczegóły transakcji.

Sprzedawca może otrzymywać 4 rodzaje zdarzeń:

  • Zdarzenie zmiany formy płatności
  • Zdarzenie zmiany adresu dostawy
  • Zdarzenie zmiany opcji dostawy
  • Zdarzenie weryfikacji sprzedawcy

Zdarzenie zmiany formy płatności

Aplikacja płatnicza może obsługiwać wiele form płatności, a sprzedawca może zaoferować specjalny rabat w zależności od wyboru klienta. W tym przypadku zdarzenie zmiany formy płatności może informować sprzedawcę o nowej formie płatności, aby mógł zaktualizować łączną cenę z rabatem i zwrócić ją z powrotem do aplikacji płatniczej.

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

Zdarzenie zmiany adresu dostawy

Aplikacja płatnicza może opcjonalnie podawać adres dostawy klienta. Jest to wygodne dla klientów, ponieważ nie muszą ręcznie wpisywać żadnych danych w formularzu, a adres dostawy mogą zostać zapisane w preferowanych aplikacjach do obsługi płatności zamiast w wielu różnych witrynach sprzedawców.

Jeśli klient zaktualizuje adres dostawy w aplikacji płatniczej po zainicjowaniu transakcji, do sprzedawcy zostanie wysłane zdarzenie 'shippingaddresschange'. To zdarzenie pomaga sprzedawcy określić koszt dostawy na podstawie nowego adresu, zaktualizować łączną cenę i zwrócić ją do aplikacji płatniczej.

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

Jeśli sprzedawca nie może wysłać zamówienia na zaktualizowany adres, może wyświetlić komunikat o błędzie, dodając parametr błędu do szczegółów transakcji zwracanych do aplikacji płatniczej.

Zdarzenie zmiany opcji dostawy

Sprzedawca może zaoferować klientowi wiele opcji dostawy i zlecić go aplikacji płatniczej. Opcje dostawy są wyświetlane w formie listy cen i nazw usług, z których klient może wybrać. Na przykład:

  • Dostawa standardowa – bezpłatna
  • Dostawa ekspresowa – 5 PLN

Gdy klient zaktualizuje opcję dostawy w aplikacji płatniczej, sprzedawca otrzyma zdarzenie 'shippingoptionchange'. Następnie sprzedawca może określić koszt dostawy, zaktualizować łączną cenę i zwrócić ją do aplikacji płatniczej.

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

Sprzedawca może także dynamicznie modyfikować opcje dostawy na podstawie adresu dostawy klienta. Jest to przydatne, gdy sprzedawca chce zaoferować różne zestawy opcji dostawy klientom krajowym i międzynarodowym.

Zdarzenie weryfikacji sprzedawcy

Aby zwiększyć bezpieczeństwo, aplikacja płatnicza może zweryfikować sprzedawcę przed przejściem do procesu płatności. Projekt mechanizmu weryfikacji należy do aplikacji płatniczej, ale zdarzenie weryfikacji sprzedawcy informuje sprzedawcę o adresie URL, którego może użyć do potwierdzenia swojej tożsamości.

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

Krok 6. Sprzedawca weryfikuje płatność i finalizuje transakcję

Gdy klient autoryzuje płatność, metoda show() zwraca obietnicę, która kończy się na PaymentResponse. Obiekt PaymentResponse zawiera te informacje:

  • Szczegóły wyniku płatności
  • Adres wysyłkowy
  • Opcja dostawy
  • Dane kontaktowe

W tym momencie w interfejsie przeglądarki nadal może być widoczny wskaźnik wczytywania, który oznacza, że transakcja nie została jeszcze zakończona.

Jeśli aplikacja płatnicza zostanie zamknięta z powodu błędu lub niepowodzenia płatności, obietnica zwrócona przez show() zostanie odrzucona, a przeglądarka zakończy transakcję płatności.

Przetwarzanie i weryfikowanie płatności

details w PaymentResponse to obiekt danych uwierzytelniających płatność zwracany z aplikacji płatniczej. Sprzedawca może użyć tych danych, aby przetworzyć lub zweryfikować płatność. Sposób działania tego ważnego procesu zależy od modułu obsługi płatności.

Realizowanie lub ponawianie transakcji

Gdy sprzedawca ustali, czy transakcja została zrealizowana, może:

  • Wywołaj metodę .complete(), aby zakończyć transakcję i zamknąć wskaźnik wczytywania.
  • Pozwól klientowi spróbować jeszcze raz, wywołując metodę 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();

Dalsze kroki