Wstęp
Strategia obejmująca wielu dostawców oznacza integrację dwóch lub więcej dostawców usług płatniczych i wprowadzenie przed nimi niewielkiej warstwy decyzyjnej, która decyduje, gdzie zostanie przeprowadzona każda transakcja.
Decyzja ta może zależeć od takich czynników, jak miejsce pobytu klienta, waluta, w której płaci, rodzaj karty lub kraj jej wydania, metoda płatności, ostatnie wyniki każdego dostawcy, wielkość transakcji, to, czy dostawca w ogóle działa w tej chwili, koszty przetwarzania, ryzykowna wydaje się płatność oraz wszelkie wymogi prawne lub umowne.
Ludzie nazywają to koordynacją płatności, inteligentnym routingiem, routingiem wieloprocesorowym lub redundancją bramki płatniczej. Etykieta się zmienia, cel pozostaje ten sam. Chcesz, aby każda transakcja nie była zależna od jednego dostawcy i jednej ścieżki w systemie.
Tego rodzaju konfiguracja ma największe znaczenie dla platform technologii finansowych, przedsiębiorstw subskrypcyjnych, rynków, handlu elektronicznego, produktów z branży turystycznej i hotelarskiej, międzynarodowych aplikacji mobilnych, portfeli cyfrowych, platform o dużej objętości oraz wszelkich przedsiębiorstw łączących kilka podmiotów prawnych lub walut.
Jest jednak pewien haczyk: samo dołączenie innego dostawcy nie zwiększa niezawodności. Bez współdzielonych identyfikatorów transakcji, jasnych reguł routingu, znormalizowanych statusów i jednego procesu uzgadniania, druga bramka może narobić więcej bałaganu, niż posprzątać.
Architektura musi umożliwiać obsługę wielu bramek płatności tak, jak jeden system płatności.
Dlaczego strategia płatności obejmująca wielu dostawców jest ważna
Z punktu widzenia klienta płacenie wydaje się proste: wpisuje dane karty, potwierdza i pojawia się ekran informujący o pomyślnym dokonaniu płatności.
W tym samym czasie jedno kliknięcie może przejść przez bramkę, procesor, bank akceptujący płatności, sieć kart, bank wydający, moduł wykrywania oszustw i usługę uwierzytelniania. Zerwanie dowolnego ogniwa w tym łańcuchu oznacza niepowodzenie transakcji.
Korzystając z usług jednego dostawcy, dziedziczysz dokładnie jedno z wszystkiego: jeden zestaw relacji z odbiorcami, jedno menu metod płatności, jeden zestaw reguł dotyczących oszustw, jedną mapę zasięgu regionalnego, jeden stos techniczny, jeden zestaw ograniczeń oraz jeden sposób raportowania i rozliczania płatności. Jeśli którykolwiek z tych elementów nie pasuje do danej płatności, nie masz planu B.
Drugi dostawca daje Ci swobodę działania. Możesz wysłać transakcję do osoby, która najprawdopodobniej ją zatwierdzi, i możesz liczyć na pomoc dostawcy zapasowego, gdy Twój główny dostawca zwolni lub przestanie działać.
Nie chodzi o to, by gromadzić bramki, bo “więcej integracji” wydaje się bezpieczniejsze. Zazwyczaj tak nie jest. Konfiguracja z wieloma bramkami opłaca się tylko wtedy, gdy generuje realne liczby biznesowe, nie generując dodatkowych kosztów operacyjnych, których nikt nie chce utrzymywać.
Dobrze wdrożone, może pomóc Ci zatwierdzić więcej płatności, zmniejszyć straty, gdy dostawca ma gorszy dzień, objąć zasięgiem więcej krajów i metod płatności oraz dać Ci przewagę w negocjacjach. Sprawia również, że wejście na nowy rynek nie jest już tak ryzykowne, sprawia, że proces płatności wszędzie wygląda tak samo, a raportowanie i uzgadnianie nie zamieniają się w domysły.
Dla założycieli i zespołów na szczeblu C interesujące pytanie nie brzmi tylko “którego dostawcę wybieramy?”" Jego “Co powinniśmy zrobić w naszym systemie płatności, jeśli pierwszy dostawca nie jest tym właściwym?”
Jak w rzeczywistości działa konfiguracja obejmująca wielu dostawców
Podstawowa architektura wielobramkowa składa się zwykle z czterech warstw:
- kasa, którą widzi klient
- wewnętrzna usługa płatnicza lub warstwa orkiestracji
- sami dostawcy płatności
- pojedyncza księga płatności i warstwa raportowania
Checkout nie musi wiedzieć ani się tym przejmować, czym różnią się dostawcy. Po prostu wysyła żądanie płatności do wewnętrznej usługi płatniczej.
Usługa ta zajmuje się resztą. Weryfikuje żądanie, tworzy wewnętrzny rekord płatności, wybiera dostawcę na podstawie Twoich reguł, wysyła transakcję, tłumaczy wszystko, co dostawca odeśle, na Twój własny format, aktualizuje status wewnętrzny, obsługuje zdarzenia webhook, które nadejdą później, i na koniec przekazuje jasny wynik klientowi, zespołowi operacyjnemu i działowi finansowemu.
Ważne jest, aby zachować to w jednym miejscu. Nie chcesz, aby logika specyficzna dla danego dostawcy przenikała jednocześnie do aplikacji mobilnej, kasy internetowej, modułu subskrypcji, panelu administracyjnego i narzędzi finansowych. Scentralizuj to, a będziesz mógł później przepisać reguły routingu bez konieczności przebudowywania całej ścieżki klienta.
1. Użyj reguł routingu, aby zwiększyć akceptację
Dostawcy różnią się pod względem rynków, metod płatności, sieci kart, banków wydających, walut czy rodzajów transakcji. Jeden może być doskonały w płatnościach kartami krajowymi, ale mierny w płatnościach kartami międzynarodowymi. Inny może oferować doskonałą obsługę przelewów bankowych, ale pobierać wyższe opłaty za zwykłe płatności kartami.
Warstwa routingu umożliwia celowy wybór dostawcy zgodnie z regułami biznesowymi, zamiast przepuszczania wszystkiego jedną drogą.
Trasowanie geograficzne
Trasa według kraju klienta, adresu rozliczeniowego, kraju wydającego lub podmiotu gospodarczego. W praktyce może to oznaczać, że transakcje w Polsce trafiają do dostawcy, który dobrze radzi sobie z BLIKIEM i płatnościami bankowymi w lokalnych bankach, klienci z Holandii otrzymują iDEAL za pośrednictwem firmy z dobrym zasięgiem lokalnym, a transakcje w USA są realizowane przez dostawcę, który ma tam odpowiednie relacje z klientami.
Trasowanie metody płatności
Żaden dostawca nie musi robić wszystkiego. Jeden obsługuje karty, drugi przelewy lokalne, a trzeci specjalizuje się w portfelach lub opcjach „kup teraz, zapłać później”. Wewnętrzna warstwa płatności ukrywa ten podział przed resztą produktu.
Trasowanie walut
Możesz kierować płatności według waluty prezentacji i rozliczeń. To ogranicza niepotrzebne przewalutowanie, upraszcza rozliczenia i pomaga w powiązaniu transakcji z odpowiednią osobą prawną i rachunkiem bankowym.
Routing oparty na wydajności
Twoja historia płatności pokazuje, który dostawca radzi sobie obecnie najlepiej w danym segmencie ruchu. Warto obserwować: wskaźnik autoryzacji, wskaźnik błędów technicznych, średni czas reakcji, wskaźnik ukończenia uwierzytelniania, wskaźnik obciążeń zwrotnych, liczbę transakcji oczekujących i częstotliwość opóźnień w dostarczaniu webhooków.
Jedno ostrzeżenie. Podejmuj te decyzje na podstawie przyzwoitej próby i stabilnego okna pomiarowego. Jeśli zareagujesz na trzy awarie z rzędu, płatności będą przeskakiwać między dostawcami bez powodu.
Trasowanie oparte na kosztach
Możesz wysyłać odpowiednie transakcje do tańszego dostawcy, o ile nie wpłynie to negatywnie na akceptację ani nie zwiększy ryzyka, na które Cię nie stać. Najtańsza ścieżka nie jest automatycznie najbardziej opłacalna. Niższa opłata nic nie znaczy, jeśli dostawca ten oferuje Ci więcej nieudanych płatności, więcej ręcznych weryfikacji i więcej uzgadniania płatności.
Trasowanie oparte na ryzyku
Bardziej ryzykowne transakcje mogą należeć do dostawcy, który dysponuje lepszymi narzędziami do wykrywania oszustw, większą liczbą opcji uwierzytelniania lub rzeczywistymi możliwościami ręcznej weryfikacji. Routing nadal musi przestrzegać przepisów. To nie jest narzędzie do omijania decyzji o ryzyku ani ponownego przesyłania płatności, która powinna pozostać nieaktywna.
2. Zaprojektuj awaryjne przełączanie bez podwójnego obciążania pracowników
Przełączanie awaryjne to prawdopodobnie najbardziej kuszący powód do dodania drugiego dostawcy. Gdy główna brama sieciowa nie działa, przekroczony zostaje limit czasu lub po prostu nie odpowiada, teoretycznie można wysłać transakcję do dostawcy zapasowego.
Przełączenie płatności jest jednak trudniejsze niż przełączanie się między dwoma standardowymi interfejsami API. Przekroczenie limitu czasu nie oznacza, że pierwszy dostawca odmówił. Może to oznaczać, że dostawca otrzymał żądanie, ale odpowiedź została utracona, płatność została autoryzowana, gdy aplikacja przestała czekać, transakcja nadal jest w toku, klient musi ponownie się uwierzytelnić lub opóźniony webhook potwierdzi rzeczywisty status za minutę.
Jeśli od razu dokonasz tej samej płatności u drugiego dostawcy, możesz obciążyć klienta dwukrotnie.
Bezpieczne przełączanie awaryjne wymaga jasnych warunków
Przed przełączeniem awaryjnym reguła powinna zadać następujące pytania: czy pierwszy dostawca faktycznie odebrał żądanie? Czy utworzono zewnętrzny identyfikator transakcji? Czy wynik jest na pewno ostateczny? Czy ta metoda płatności obsługuje bezpieczne ponawianie? Czy klient musi się ponownie uwierzytelnić? Czy użyto mechanizmów kontroli idempotentności dostawcy? Czy należy najpierw przeprowadzić kontrolę statusu?
Pomaga to przyporządkować każdą sytuację do jednego z trzech przedziałów: dostawca jest potwierdzony jako niedostępny, transakcja zdecydowanie nie powiodła się lub stan jest nieznany. Tylko dwa pierwsze przypadki są dopuszczalne w przypadku kontrolowanego przełączania awaryjnego. Nieznany stan powinien uruchamiać sprawdzanie statusu dostawcy lub oczekujący przepływ pracy, a nie naliczać drugiego obciążenia.
Więcej informacji na temat ochrony przed zduplikowanymi zdarzeniami i obsługi stanu bezpiecznego można znaleźć w naszym artykule na temat webhooki i idempotentność w integracji bramek płatniczych.
Celowe testowanie przełączania awaryjnego
Twój plan zapewnienia jakości powinien symulować najgorsze, a nie najgorsze przypadki: awarie połączeń, powolne odpowiedzi i przekroczenia limitu czasu, błędne dane uwierzytelniające, ograniczanie przepustowości, nieudane uwierzytelnianie, opóźnione webhooki, zduplikowane webhooki, dostawca odzyskujący dane po awarii, częściowa awaria obejmująca tylko jedną metodę płatności oraz płatność zrealizowana na ułamek sekundy przed przekroczeniem progu przełączania awaryjnego.
System powinien również pokazywać swoją pracę. Operatorzy muszą zobaczyć, który dostawca został wypróbowany, jakie były wyniki i dlaczego nastąpiła lub nie nastąpiła awaryjna reinstalacja.
3. Znormalizuj statusy dostawców
Każdy dostawca ma swój własny słownik, model reakcji i cykl życia. Jeden zwraca `autoryzowany`, inny `udało się`, inny `zatwierdzono`. Również oczekujące, przechwycone, anulowane, cofnięte, zwrócone, kwestionowane i nieudane mogą zachowywać się nieco inaczej.
Jeśli statusy specyficzne dla dostawcy będą wyciekać do całego produktu, oznacza to lata uciążliwej konserwacji. Zamiast tego zbuduj wewnętrzny model stanu płatności.
Przykładowy, znormalizowany cykl życia mógłby wyglądać następująco: utworzone, przetwarzane, wymagane uwierzytelnienie, autoryzowane, przechwycone, nieudane, anulowane, częściowo zwrócone, zwrócone, kwestionowane, cofnięte oraz nieznane lub w trakcie przeglądu.
Każda odpowiedź dostawcy i zdarzenie webhooka są mapowane na ten współdzielony model. Zachowaj oryginalny status dostawcy na potrzeby rozwiązywania problemów i audytów, ale pozwól reszcie produktu mówić Twoim językiem, a nie językiem bramy. W ten sposób proces realizacji transakcji, narzędzia wsparcia, zarządzanie zamówieniami i raportowanie używają tych samych słów, niezależnie od tego, która brama uruchomiła transakcję.
4. Twórz raporty obejmujące dostawców
Strategia obejmująca wielu dostawców zwiększa Twoją odporność, a jeśli nie zachowasz ostrożności, utrudnia również raportowanie.
Bez ujednoliconego modelu Twój zespół loguje się do kilku pulpitów nawigacyjnych, eksportuje niezgodne formaty CSV, porównuje definicje statusów, które się nie zgadzają, ręcznie dopasowuje wypłaty, sumuje opłaty dostawców w arkuszach kalkulacyjnych i śledzi tę samą płatność w trzech systemach. Twoja wewnętrzna platforma płatności powinna zamiast tego zapewnić im jeden skonsolidowany widok.
Co powinien zawierać ujednolicony rejestr płatności
Każda płatność wymaga stałego wewnętrznego identyfikatora, który nie należy do żadnego dostawcy. Wokół tego identyfikatora przechowuj numer zamówienia, faktury lub rezerwacji, identyfikator klienta, wybranego dostawcę, identyfikator transakcji dostawcy, metodę płatności, żądaną kwotę i walutę oraz kwoty autoryzowane, zarejestrowane i zwrócone.
Następnie kontekst operacyjny: Twój status wewnętrzny, status oryginalnego dostawcy, uruchomiona reguła routingu, numer próby, wynik uwierzytelniania, kategoria niepowodzenia, szczegóły opłat, numer referencyjny rozliczenia oraz znaczniki czasu utworzenia i aktualizacji.
Jeśli płatność dotyczy więcej niż jednego dostawcy, każda próba powinna być powiązana z tym samym wewnętrznym rekordem. Wtedy będziesz mógł odpowiedzieć na pojawiające się pytania: który dostawca został sprawdzony jako pierwszy, dlaczego routing go wybrał, czy uruchomiono kopię zapasową, która próba spowodowała ostateczne obciążenie, czy klient zakończył uwierzytelnianie, czy pieniądze zostały przechwycone, do której wypłaty trafiły oraz czy opłaty i zwroty się zgadzają.
5. Zachowaj spójność uzgodnień
Uzgadnianie polega na potwierdzeniu, że dane zarejestrowane przez Twój produkt są zgodne z raportami dostawcy, wypłatami, opłatami, zwrotami, sporami i depozytami bankowymi. Z jednym dostawcą jest to wystarczająco trudne. Przy kilku, niedbałe uzgadnianie szybko staje się realnym ryzykiem operacyjnym.
Na przykład dokumentacja Adyen ujmuje uzgadnianie jako śledzenie przetwarzania płatności i rozliczeń za pomocą raportów dostawców, a przewodniki rozliczeniowe oddzielają aktywność transakcji od partii wypłat. To właśnie jest sednem sprawy: sam wewnętrzny status płatności nie wystarczy, ponieważ trzeba również powiązać transakcje z danymi rozliczeniowymi. Zapoznaj się z wytycznymi Adyen dotyczącymi uzgadniania płatności.
Użyj jednego wewnętrznego rejestru
Twój wewnętrzny rejestr powinien być źródłem prawdy dla cyklu płatności na poziomie biznesowym. Importuj raporty dostawców i porównuj je z nimi, zamiast pozwalać, aby raporty każdego dostawcy stały się odrębną, konkurencyjną prawdą.
Przechowuj przepływy finansowe jako osobne rekordy: autoryzacja, przechwycenie, zwrot, częściowy zwrot, obciążenie zwrotne, cofnięcie obciążenia zwrotnego, opłata manipulacyjna, przewalutowanie, korekta rezerwy, wypłata i korekta ręczna. Dzięki temu możesz wyjaśnić, dlaczego płatność klienta w wysokości 100 euro nie przekształciła się w depozyt bankowy w wysokości 100 euro.
Oddziel status transakcji od statusu rozliczenia
Płatność może zostać zrealizowana dla klienta, ale nadal nie zostać rozliczona. Należy zachować te dane w różnych polach: status płatności klienta, status przechwycenia, status zwrotu lub sporu, status uzgodnienia, status rozliczenia i numer referencyjny wypłaty. W przeciwnym razie “zapłacono” po cichu traktowane jest jako “dopasowane, rozliczone i zalegające w banku”, czym nie jest.
Zautomatyzuj dopasowywanie
Zadania uzgadniania powinny być zgodne w odniesieniu do stabilnych referencji: identyfikatora transakcji dostawcy, referencji sprzedawcy, identyfikatora płatności wewnętrznej, identyfikatora przechwycenia, identyfikatora zwrotu, identyfikatora partii rozliczeń, identyfikatora wypłaty. Sprawdź kwoty i waluty zamiast im ufać. Wszystko, co nie jest zgodne, trafia do kolejki wyjątków, aby mógł to sprawdzić człowiek.
Typowe problemy w tej kolejce: brakujące zapisy dostawców, nieznane transakcje, różnice kwot lub walut, podwójne rozliczenia, zwroty pieniędzy bez zgodnej pierwotnej płatności, obciążenia zwrotne, które jeszcze nie pojawiły się wewnętrznie, opłaty, których nie można przypisać, oraz płatności oznaczone jako pomyślne, które nigdy nie pojawiają się w raporcie rozliczeniowym.
6. Sprawdź, czy cokolwiek z tego działa
Oceniaj konfigurację wielobramkową na podstawie mierzalnych rezultatów, a nie tego, jak skomplikowana się wydaje.
Współczynnik autoryzacji. Podziel to według dostawcy, rynku, rodzaju karty, metody płatności i reguły routingu. Zdrowa globalna średnia może łatwo ukryć jedną trasę, która po cichu zawodzi.
Wskaźnik awaryjności technicznej. Śledź płatności, które zostały anulowane z powodu błędów bramki płatniczej, przekroczenia limitu czasu, błędnych odpowiedzi lub niedostępnych usług i oddziel tę liczbę od uczciwych odrzuceń.
Współczynnik odzyskiwania po awarii. Zmierz, ile kwalifikujących się transakcji dostawca kopii zapasowej odzyskuje po awarii głównej trasy, a także, jak często następuje blokowanie przejścia w tryb failover, ponieważ pierwszy wynik był nieznany.
Stawka za podwójną płatność. Ten powinien oscylować wokół zera. Nawet kilka podwójnych opłat generuje zgłoszenia do pomocy technicznej i podważa zaufanie.
Opóźnienie płatności. Zwróć uwagę na czas potrzebny na rozpoczęcie, uwierzytelnienie i potwierdzenie płatności. Trasowanie nie powinno zapewnić Ci wyższego wskaźnika akceptacji za cenę przedłużającego się procesu płatności.
Współczynnik dopasowania uzgodnień. Śledź, jaki procent transakcji i rozliczeń z dostawcami automatycznie się zgadza. Niska wartość oznacza, że po prostu po cichu przeniosłeś koszty na zespół finansowy.
Koszt każdej udanej płatności. Oblicz to na podstawie pozytywnych wyników, a nie reklamowanej opłaty transakcyjnej. Uwzględnij opłaty za bramkę i akwizycję, koszty uwierzytelniania, przewalutowanie, opłaty za zwroty i reklamacje, konserwację techniczną, ręczną weryfikację oraz obciążenie pracą związaną z uzgadnianiem.
Typowe błędy w przypadku wielu bramek
Dodawanie dostawców bez jasnego uzasadnienia biznesowego. Drugi dostawca wnosi do firmy rozwój, zapewnienie jakości, zgodność, raportowanie i utrzymanie. Z góry zdecyduj, co ma poprawić: akceptację, odporność, zasięg, koszty czy dostępność metod płatności.
Próba powtórzenia każdego spadku gdzie indziej. Wiele odrzuceń nie powinno być w ogóle ponawianych. Całkowite odrzucenie, podejrzenie oszustwa, nieważna karta lub blokada regulacyjna nie stają się bezpieczne tylko dlatego, że inny dostawca jest gotowy do działania.*Traktuj panele dostawców jako jedyne źródło raportów. Są to przydatne narzędzia operacyjne, ale żaden pojedynczy panel nie przedstawia obrazu obejmującego wszystkich dostawców.
Traktowanie przejścia w tryb failover jako zwykłej ponownej próby wykonania funkcji API. Pierwsze żądanie mogło zostać zrealizowane pomyślnie, nawet jeśli Twoja aplikacja nigdy nie otrzymała odpowiedzi.
Ignorowanie zwrotów pieniędzy i sporów. Architektura musi obejmować cały cykl życia, a nie tylko pierwsze zamówienie.
Nikt nie potrafi wyjaśnić zasad tworzenia tras. Rejestruj decyzje i dbaj o to, by były zrozumiałe. Każda reguła, która zmienia wybór dostawcy, potrzebuje właściciela, celu i rezultatu, na który można wskazać.
Optymalizacja wyłącznie pod kątem opłat za przetwarzanie. Akceptacja, obciążenie za obsługę, złożoność rozliczeń i zaufanie klienta często mają większe znaczenie niż obniżenie opłaty o kilka punktów bazowych.
Często zadawane pytania
Czy każda firma potrzebuje wielu bramek?
Nie. Produkt na wczesnym etapie rozwoju, o niewielkim wolumenie, jednym rynku i prostych wymaganiach, zazwyczaj lepiej sprawdza się w przypadku jednej, dobrze zaprojektowanej integracji. Współpraca z wieloma dostawcami zaczyna przynosić zyski, gdy przestoje, wydajność regionalna, dostępność metod płatności lub wskaźniki akceptacji zaczynają w odczuwalny sposób zwiększać przychody.
Bezpośrednia integracja czy platforma orkiestracji?
Bezpośrednie integracje dają większą kontrolę, ale pozwalają samodzielnie tworzyć narzędzia do routingu, normalizacji, raportowania i obsługi. Platforma orkiestracji oszczędza część początkowego nakładu pracy inżynieryjnej, ale generuje koszty platformy, zależności umowne i kolejny etap w przepływie. Właściwa odpowiedź zależy od wolumenu, zespołu, potrzeb w zakresie zgodności, rynków oraz tego, jak centralna jest logika płatności w Twojej firmie.
Czy możemy automatycznie ponowić nieudaną płatność za pośrednictwem innego dostawcy?
Czasami. Tylko wtedy, gdy pierwsza próba ma znany status końcowy, a ponowna próba jest dozwolona dla danej metody płatności i rodzaju błędu. Nieznane wyniki wymagają sprawdzenia przed ponownym obciążeniem kogokolwiek opłatą.
Czy większa liczba dostawców automatycznie zwiększy akceptację?
Nie. Akceptacja wzrasta tylko wtedy, gdy routing opiera się na rzeczywistych danych, a dostawcy faktycznie działają inaczej w poszczególnych segmentach transakcji.
Jak uniknąć podwójnych opłat?
Wewnętrzne identyfikatory płatności, mechanizmy idempotencji dostawców, rejestry prób, sprawdzanie stanu, prawidłowe przetwarzanie webhooków i rygorystyczne zasady przełączania awaryjnego. Dokumentacja Stripe porusza ten sam temat: zachowanie ponawiania prób musi uwzględniać stan płatności i kwalifikowalność ponowienia, zamiast traktować każdą awarię tak samo. Zobacz oficjalne wytyczne firmy Stripe dotyczące automatycznych ponawianych prób płatności.
Jak finanse powinny działać w różnych obszarach?
Zapewnij im jeden skonsolidowany widok raportowania i uzgadniania. Raporty dostawców nadal mają znaczenie, ale Twoja wewnętrzna księga rachunkowa powinna normalizować referencje, statusy, opłaty, wypłaty, zwroty i spory.
Jak Appricotsoft tworzy integracje płatności między wieloma dostawcami
W Appricotsoft traktujemy integrację bramek płatniczych jako produkt i system operacyjny, a nie zbiór niepowiązanych ze sobą połączeń API. Naszym celem jest oprogramowanie, które jest naprawdę użyteczne, niezawodne i z którego nasz zespół i nasi klienci są naprawdę zadowoleni.
Zacznijmy od analizy biznesowej
Zanim dodamy drugą bramkę, ustalamy, co ma ona osiągnąć. Zazwyczaj jest to coś konkretnego: zwiększenie akceptacji na danym rynku, obsługa lokalnej metody płatności, zmniejszenie zależności od jednego dostawcy, ochrona przychodów w przypadku incydentów, obsługa innej waluty lub podmiotu prawnego lub zapewnienie firmie większego pola manewru komercyjnego. Dzięki temu projekt nie przekształci się w kosztowną integrację bez wymiernych korzyści.
Mapujemy cały cykl życia
Dokumentujemy przepływ od momentu utworzenia płatności, poprzez wybór dostawcy, uwierzytelnianie, autoryzację, przechwytywanie, przetwarzanie webhooków, zwroty, spory, uzgadnianie, rozliczenie i dochodzenie w sprawie pomocy technicznej. Wczesne mapowanie pozwala wykryć luki, zanim staną się incydentami produkcyjnymi.
Tworzymy wspólny model płatności
Wprowadzamy wewnętrzne identyfikatory transakcji, znormalizowane statusy, spójne kategorie błędów i rekordy dla każdej próby. Twój produkt działa w oparciu o jeden, stabilny model płatności, a adaptery dostawców eliminują specyficzne dla danej bramki płatności osobliwości.
Projektujemy routing i failover w środowisku otwartym
Każda reguła routingu musi mieć uzasadnienie. Zapisujemy warunki wejściowe, wybranego dostawcę, zachowanie awaryjne, warunki zatrzymania, metrykę monitorowania i właściciela operacyjnego. Dzięki temu system jest czytelny zarówno dla działu produktu, inżynierii, wsparcia, jak i finansów.
Wprowadzamy pojednanie do architektury
Uzgadnianie nie jest czymś, co dodajemy od razu po uruchomieniu. Definiujemy referencje dostawców, importy rozliczeń, obsługę wyjątków i wymagania dotyczące raportowania, gdy integracja rdzenia jest jeszcze w trakcie tworzenia. Dla zespołów, które tworzą swój pierwszy produkcyjny przepływ płatności, nasza lista kontrolna wdrożenia bramki płatniczej obejmuje środowiska, poświadczenia, webhooki, mapowanie błędów, testowanie i monitorowanie uruchomienia.
Testujemy trudne scenariusze
Testowanie na ścieżce testowej (happy-path checkout) to punkt wyjścia, w którym testowanie się zaczyna, a nie kończy. Wspomagamy się przekroczeniami limitu czasu, opóźnionymi powiadomieniami, zduplikowanymi zdarzeniami, nieznanymi stanami, częściowymi zwrotami kosztów, awariami dostawców, nieudanymi rozwiązaniami awaryjnymi i rozbieżnościami w rozliczeniach.
Utrzymujemy widoczność dostawy
Nasz Unison Framework łączy klienta, zespół Appricotsoft i odpowiedzialne narzędzia AI w jednym procesie dostaw. AI pomaga nam tworzyć scenariusze testowe, przeglądać logi, udoskonalać dokumentację i redukować powtarzalne zadania. To ludzie nadal ponoszą odpowiedzialność za decyzje architektoniczne, weryfikację, bezpieczeństwo i decyzję o gotowości do wydania. Dzięki przejrzystym backlogom, logiom decyzyjnym, śledzeniu ryzyka, kontrolom jakości i regularnym demonstracjom, klienci obserwują postęp prac i rozumieją kompromisy, zanim przerodzą się one w kosztowne poprawki.
Wniosek
Strategia wielodostawców może zwiększyć akceptację, zwiększyć odporność i poszerzyć zasięg rynkowy. Dzieje się tak jednak tylko wtedy, gdy dostawcy korzystają ze spójnej architektury wewnętrznej.
Nie liczy się liczba obsługiwanych bramek. Liczy się struktura: jasne reguły routingu, bezpieczne warunki przełączania awaryjnego, niezależne od dostawcy identyfikatory transakcji, znormalizowane statusy, ujednolicone raportowanie, niezawodna księga wewnętrzna, automatyczne uzgadnianie i metryki widoczne dla zespołu operacyjnego. Pomiń ten fundament, a drugi dostawca po prostu podwoi liczbę integracji, pulpitów nawigacyjnych i wyjątków, którymi musi zarządzać Twój zespół. Zbuduj go, a kilku dostawców zacznie działać jak jedna platforma płatnicza, dając Ci większą kontrolę bez komplikowania procesu płatności dla klienta.
Appricotsoft pomaga firmom fintech, marketplace'om, platformom hotelarskim, firmom subskrypcyjnym i zespołom ds. produktów mobilnych projektować i budować niezawodne architektury płatności. Niezależnie od tego, czy dodajesz bramkę zapasową, wkraczasz na nowe rynki, dążysz do lepszej akceptacji, czy zastępujesz plątaninę niepowiązanych integracji jedną, spójną warstwą płatności, pomożemy Ci rozważyć kompromisy i opracować praktyczny plan działania.
Planujesz wdrożenie płatności u wielu dostawców? Poproś Appricotsoft o wycenę oprogramowania, abyśmy mogli zaprojektować architekturę płatności, która pozostanie niezawodna wraz z rozwojem Twojej firmy.
