Collecting Payment Service Provider (CPSP) opzetten (PHP)

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • powershift
  • Registratie: Oktober 2018
  • Laatst online: 22-06-2022
Goedemorgen,

Ik heb een vraag, ik heb een discussie gehad met een goede vriend en eigenlijk ben ik nieuwsgierig geworden naar het opzetten van een eigen CPSP zoals ik begrijp dat het heet. Een soort Mollie / Stripe / Multisafepay concurrent.

Ik ben voornamelijk heel nieuwsgierig naar de uitdaging. Nou hoop ik niet dat deze post op gronde daar alleen van al wordt afgeschoten. Maar hierbij mijn vraag.

Ik ben inmiddels dusdanig ver dat ik weet dat je gebruik moet maken van stichting derdegelden, ik weet dat je een verklaring van goed gedrag moet hebben.

Maar hoe je begint? Dat is mij nog volstrekt onduidelijk. Wie biedt de API's aan? Waar moet ik mij melden.
Hoe kan ik überhaupt voor mijzelf een proof of concept opzetten?

Misschien hele n00b vragen.
Maar Google biedt heel veel antwoorden welke payment service providers er bestaan. Maar niet hoe je er zelf een opzet.

Ik zoek misschien verkeerd, dus vergeef mij in dat geval. Maar ik hoop dat jullie mij wel de goede richting op kunnen sturen.

Acties:
  • +1 Henk 'm!

  • ThomasG
  • Registratie: Juni 2006
  • Laatst online: 23:35
Je hebt eerst een vergunning als betalingsdienstverlener nodig (wettelijk verplicht). Vervolgens kun je onder PSD2 betalingen afhandelen. Hoe en wat staat beschreven in allerlei standaarden, niet zozeer een API. Een eventuele API tussen jullie service en websites/apps zul je natuurlijk zelf moeten bedenken.

Acties:
  • 0 Henk 'm!

  • powershift
  • Registratie: Oktober 2018
  • Laatst online: 22-06-2022
ThomasG schreef op dinsdag 12 april 2022 @ 11:47:
Je hebt eerst een vergunning als betalingsdienstverlener nodig (wettelijk verplicht). Vervolgens kun je onder PSD2 betalingen afhandelen. Hoe en wat staat beschreven in allerlei standaarden, niet zozeer een API. Een eventuele API tussen jullie service en websites/apps zul je natuurlijk zelf moeten bedenken.
Ik begrijp wat je bedoeld. Ook betreffende de API.
Het deel van onder de toezichthouder staan is natuurlijk logisch.

Wat ik nog niet helemaal snap is het deel dat ertussen ligt.

#1 Je hebt de klant die een betaling initieert via de webshop / online dienst

#2 De online applicatie (webshop / dienst) maakt via de API connectie met de Payment Service Provider en geeft alle benodigde parameters mee. (Bedrag, Omschrijving, (api sleutel natuurlijk logisch), callback URL, retour URL

#3 Payment Service Provider registreert het betalingsverzoek en geeft alle benodigde parameters aan de webshop terug inclusief de start URL.

#4 De online applicatie stuurt de klant door naar de URL ontvangen van de Payment Service Provider.

#5 De Payment Service Provider geeft een overzicht van alle banken waarbij de klant kan betalen. (uitgaande van iDeal)

Hierbij al direct mijn eerste vraag hierop, de lijst met banken. Is dat een lijst met banken die de Payment Service Provider ergens heeft opgeslagen, hardcoded / database. OF is dat een lijst die de Payment Service Provider ergens ophaalt? Bij de DNB bijvoorbeeld.

#6 Na keuze door de klant van zijn bank. Maakt de Payment Service Provider een connectie met de bank naar keuze. En geeft hij de benodigde gegevens aan deze bank door.

Hierbij mijn tweede vraag. Deze gegevens die doorgegeven worden aan de bank van keuze. Dat is natuurlijk wel via een API. Maar is dat een universele API? Is dat een API die per bank aangesloten moet worden? Dus als ik de RaboBank wil ondersteunen moet ik de Rabo API implementeren. Als ik de ING wil aanbieden als betaaloptie. Moet ik dan los daarvan de ING API implementeren?

#7 De klant maakt zijn betaling bij de bank naar keuze. En deze geeft het resultaat terug aan de Payment Service Provider.
Maar ook dat wordt weer op een bepaalde manier door-gekoppeld, maar ook dat gebeurt weer via een API neem ik aan.


Nu begrijp ik dat het niet de bedoeling dat je alles voor mij gaat voorkauwen. Maar mijn grote vraagteken zit er in het deel. Hoe zit het met de tussenstap. Waarbij mijn Payment Service Provider contact legt met de bank en onderhoudt.

Acties:
  • 0 Henk 'm!

  • Kalentum
  • Registratie: Juni 2004
  • Nu online
Elke betalingsmethode heeft een API die beheert wordt door de eigenaar van de betalingsmethode. De eigenaar van iDeal is Currence https://www.ideal.nl/partners/ en ik ga er zonder meer van uit dat zij een API hebben die door Mollie etc gebruikt wordt, inclusief een lijstje van banken bijvoorbeeld.

Ik weet niet exact of je per bank nog wat moet doen als PSP, ik ga ervanuit van niet en dat Currence dat allemaal voor je afhandelt.

Maar goed, techniek is niet je grootste probleem als je een Mollie wilt worden

Acties:
  • 0 Henk 'm!

  • dev10
  • Registratie: April 2005
  • Laatst online: 14-05 14:52
Wat verder nog even interessant is, zijn de tarieven die Currence rekent voor CPSP en Acquirers: https://www.currence.nl/c...ten/ideal/tarieven-ideal/

Ik weet niet of je hier überhaupt van op de hoogte was, maar daarvoor mag je een flinke bak met geld mee gaan nemen.

Acties:
  • 0 Henk 'm!

  • DJMaze
  • Registratie: Juni 2002
  • Niet online
@dev10 dat inderdaad, + de auditing kosten voor PSD2 en credit cards.

Maak je niet druk, dat doet de compressor maar


Acties:
  • +1 Henk 'm!

  • Voutloos
  • Registratie: Januari 2002
  • Niet online
Naast wat al genoemd is; boekhouding, facturen/specificaties opmaken, procedures, draaiboeken, scheiding van rollen, bestuur, vier ogen principes, KYC, monitoring, fraudedetectie, audits.

In iets sufs als KYC kan al verrassend veel tijd gaan zitten.

Samengevat: De techniek van je betaal-API staat met moeite in de top 10 grote issues.

Bron: Bij vorige werkgever een CPSP begonnen. Toen de markt iets minder verzadigd was. En die instaptarieven nog iets lager.

TL;DR: Ik wens je veel succes. ;)

{signature}


Acties:
  • +2 Henk 'm!

  • BeardyCode
  • Registratie: November 2019
  • Laatst online: 08-03 17:57
Je lijkt voornamelijk interesse te hebben in het programmeer gedeelte van dit project.
Terecht natuurlijk, dat is verreweg het leukste. Maar het schrijven hiervan, zeker als je een beetje bekend bent met programmeren, is echt niet zo uitdagend.

Als je het voor de uitdaging doet, kan je vandaag nog beginnen aan talloze projecten, of natuurlijk bijdragen aan open source projecten, die vele malen uitdagender zijn dan het programmeren van een payment gateway.

@Voutloos geeft het hierboven eigenlijk goed aan. Voordat je kan beginnen met ook maar één regel code schrijven heb je waarschijnlijk al voorwerk nodig in de richting van tientallen, misschien wel honderden duizenden euro's.

Daarnaast is de markt ontzettend killing en (volgens mij) zijn de marges inmiddels heel klein. Enkel rendabel omdat de genoemde payment gateways miljoenen transacties per dag afhandelen.
Er is natuurlijk een reden day PayPal zakt in populariteit. Ooit marktleider, nooit de concurrentie serieus genomen.

De laatste keer dat ik keek vroeg PayPal nog iets belachelijks als 29 cent + 4,5% van het aankoopbedrag per transactie. Mollie (en ik meen Stripe ook) zitten inmiddels rond de 23 cent per transactie.

Waarschuwing genoeg in de posts boven mij, maar toch nog maar eentje dan... Het gaat een helse weg worden.
Pagina: 1