Delivery 1.0 Help

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-marketplace-iso-1.png

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:


BM*allegro or BM*allegro.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

    • 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

payfac-marketplace-iso.png

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

payfac-marketplace-iso-3.png

Marketplace Bypass

payfac-marketplace-iso-4.png
  • 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

Last modified: 30 May 2024