PayFac / Marketplace / ISO
Lets ask Chat GPT
Question
Jesteś ekspertem w temacie usług płatniczych. Masz długoletnią wiedzę i świetnie znasz wszystkie model płatności. Masz przygotować materiał w którym przygotujesz informacje o tym jak działa model ISO, Payment Facilitator (inaczej nazywa się PayFac) oraz marketplace. Masz wskazać różnice zarówno w aspekcie biznesowym jak i technicznym. Możesz skorzystać z aktualnych źródeł (internet). Pamiętaj że jesteś ekspertem i wypowiadaj się jak ekspert.
Answer
Model ISO (Independent Sales Organization) i model Payment Facilitator (PayFac) to dwa popularne modele w świecie usług płatniczych. Oba modele pełnią rolę pośredników, zapewniając dostawcom usług dostęp do systemu płatności w imieniu swoich partnerów bankowych.
ISO i PayFac różnią się pod wieloma względami:
Umowy i relacje z handlowcami: W przypadku ISO, bank-sponsor musi być stroną umowy, podczas gdy zasady karty umożliwiają dwustronne umowy pomiędzy PayFac a sub-handlowcem. PayFac posiada własne portfolio sub-handlowców i może przenosić je od jednego sponsora do drugiego, podczas gdy dla ISO, własność i przenośność portfolio zależy od umowy (1).
Aplikacje, onboardingu i monitorowania: PayFac jest zwykle odpowiedzialny za ryzyko stwarzane przez handlowców w swoim portfolio, co wpływa na sposób, w jaki obsługuje aplikacje handlowców, procesy onboardingu i monitorowania. ISO mają różne poziomu odpowiedzialności, zależne od umowy z ich sponsorem. PayFac mają pewną swobodę w tworzeniu własnych procesów w tych obszarach, pod warunkiem, że działają one w ramach zasad wyznaczonych przez sponsora. W przeciwnym razie, sponsorem zwykle narzucają surowsze ograniczenia dla ISO (2).
Finansowanie: PayFac ma większą swobodę w wyborze sposobu prowadzenia swojej działalności. Może wybrać, aby dokonywać płatności z konta bankowego, które posiada i/lub kontroluje. ISO natomiast nie ma prawa dotykać środków. Rozliczenie musi nastąpić bezpośrednio od sponsora do handlowca (3).
Model PayFac przynosi korzyści z większej kontroli nad doświadczeniem, które oferuje swoim klientom, co często prowadzi do konkurencyjnej przewagi na rynku. Może to skutkować poprawą sprzedaży i mniejszym odsetkiem rezygnacji klientów. PayFac pobiera również opłatę za przetwarzanie płatności, co stanowi dodatkowe źródło przychodów dla firmy (4). W celu stania się PayFac, firma musi najpierw ocenić, czy ROI z tego modelu będzie pozytywne. Generalnie, jeśli firma przetwarza ponad 50 milionów dolarów transakcji za pośrednictwem swojego oprogramowania, to ROI z adopcji modelu PayFac jest sensowne (5). Firma musi również opracować polityki i procedury dotyczące oceny i monitorowania sub-handlowców, a także mieć infrastrukturę płatniczą, która umożliwi prawidłowe onboarding i obsługę sub-handlowców (6). Następnie, firma musi podpisać umowę ze sponsorem (bankiem nabywającym i procesorem). Po zatwierdzeniu, PayFac otrzymuje identyfikator PayFac (PFID) i może rozpocząć ocenę, onboarding i obsługę swoich sub-handlowców (7).
Rozwój firm software'owych, które skorzystają z dodania płatności do swojej oferty, spowodował potrzebę lepszego ekosystemu płatności. Model PayFac pomaga rozwiązać ten problem, oferując firmom dodatkowe strumienie przychodów i większą kontrolę nad doświadczeniem klientów. Mimo znacznych kosztów związanych z uruchomieniem jako PayFac, korzyści są oczywiste. Oczekuje się, że liczba firm działających jako PayFac znacznie wzrośnie w najbliższych latach, co doprowadzi do znacznej ekspansji akceptacji płatności elektronicznych na świecie (8).
Model Marketplace, z drugiej strony, polega na tworzeniu platformy, która umożliwia sprzedawcom i kupującym spotkanie się i dokonanie transakcji. Marketplace nie tylko umożliwia sprzedawcom i kupującym spotkanie się i dokonanie transakcji, ale także oferuje platformę dla różnych stron trzecich do sprzedaży swoich towarów. Operator platformy marketplace jest odpowiedzialny za obsługę płatności, rozliczeń, obsługę klienta i dostarczanie jak najlepszego doświadczenia użytkownika. Modele biznesowe Marketplace ewoluowały, aby zapewnić lepsze doświadczenie dla użytkowników, zwiększenie sprzedaży, niższe opłaty i zwiększone zyski.
Systemy płatności dla modelu Marketplace, takie jak Stripe Connect, umożliwiają firmom zintegrowanie płatności bezpośrednio do ich aplikacji oprogramowania, dzięki czemu mogą łatwo obsługiwać zarówno sprzedawców, jak i kupujących na ich platformach.
Podsumowując, zarówno ISO, PayFac, jak i Marketplace to modele usług płatniczych, które mają swoje unikalne cechy i korzyści. Wybór pomiędzy nimi zależy od specyficznych potrzeb i celów biznesowych firmy.
Acquirer vs Payment Facilitator
Pay Fac
Payment institution
Its not one model
Involved in agreement
Involved in funds
Sometimes involved in technology
Sometimes involved in payment
Nearly always own brand

PayFac vs Acquirer
Acquirer | PayFac | |
|---|---|---|
Structure | Has many merchants | For acquirer its still merchant but big one with many merchant behind For PayFac he has many submerchants |
Merchant | Only | PayFac is merchant |
SubMerchant | None | Only |
Descriptor | Just merchant data like: allegro or allegro.pl | Needs to be PayFac ID + merchant name like:
|
Agreement | Agreement with merchants | Agreement with acquirer as merchant Agreement with submerchants |
Onboarding | Merchants | Most often approved policy by Acquirer and do by its own |
PCI | Yes | Only if involved in payment |
Processing | Yes | Sometimes and only if involved in payment |
Funds | Direct to merchant | From acquirer and then to submerchant |
Risk | Has full risk | Still acquirer has full risk but most often delegate it to PayFac |
Technical case
Double level of merchant (merchant and sub merchant) → to be honest even “four levels” of merchant:
Merchant - legal entity
Acceptor - business entity
Submerchant - legal entity
Subacceptor - business entity
We need to build proper descriptors and proper DE for PayFac
ISO vs Payment Facilitator
Independent Sales Organization
Not need to be Payment institution
Its not one model
Involved in agreement as a third party or agent
Involved in funds (sometimes but its not kosher)
Sometimes involved in technology
Sometimes involved in payment
Most often own brand

ISO vs Acquirer
Acquirer | ISO | |
|---|---|---|
Structure | Has many merchants | ISO merchants are also acquirers merchants so no changes |
Merchant | Only | no own merchants |
SubMerchant | None | None |
Descriptor | Just merchant data like: allegro or allegro.pl | Just merchant data like: allegro or allegro.pl |
Agreement | Agreement with merchants | Agreements directly between Acquirer and Merchant and optional ISO |
Onboarding | Merchants | By acquirer |
PCI | Yes | Only if involved in payment |
Processing | Yes | Sometimes and only if involved in payment |
Funds | Direct to merchant | Direct to merchant |
Risk | Has full risk | Still acquirer has full risk but most often delegate it to ISO |
Technical case
Just information about brands
No additional needs
Marketplace vs Payment Facilitator
Company which provide shop by its own brand but its not selling own products from many sellers.
Marketplace
In official model needs to be Payment Institution
There is some bypass
Has agreement with buyer and seller
Involved in funds
Sometimes involved in technology
Sometimes involved in payment
Most often own brand

Marketplace Bypass

Marketplace sign agreements with seller
PSP also sign agreement with seller
Customer is buying on marketplace by accepting T&C of PSP and Marketplace
Customer is paying to PSP
PSP is sending funds to:
Marketplace = commission
Seller = amount - commission
Marketplace vs Acquirer
Acquirer | Marketplace | |
|---|---|---|
Structure | Has many merchants | For acquirer its still merchant but big one with many merchant behind For Marketplace he has many submerchants |
Merchant | Only | Marketplace is merchant |
SubMerchant | None | Only |
Descriptor | Just merchant data like: allegro or allegro.pl | Needs to be Marketplace ID + merchant name like: XXallegro or BMallegro.pl |
Agreement | Agreement with merchants | Agreement with acquirer as merchant Agreement with submerchants |
Onboarding | Merchants | Most often approved policy by Acquirer and do by its own |
PCI | Yes | Only if involved in payment |
Processing | Yes | Sometimes and only if involved in payment |
Funds | Direct to merchant | From acquirer and then to submerchant |
Risk | Has full risk | Still acquirer has full risk but most often delegate it to PayFac |
Technical case
Double level of merchant (merchant and sub merchant) → to be honest even “four levels” of merchant:
Merchant - legal entity
Acceptor - business entity
Submerchant - legal entity
Subaccepto - business entity
We need to build proper descriptors and proper DE for Marketplace
source: (idea of merchant structure) Silverflow API documentation