Maxn

Nee, het deel van PSD2 waar we het momenteel over hebben is rekeninginformatiediensten Dat zijn o.a. online boekhoudpakket koppelingen met partijen als Exact, Moneybird, Informer, Snelstart en Twinfield. En koppelingen met online huishoud boekjes zoals Afas Personal. Voor de technische onderlegden: als je wilt zien welke gegevens er worden overgezonden, de gebruikte APIs staan ook gewoon netjes gedocumenteerd op de sites van de diverse banken. Bijv. ING: https://developer.ing.com/api-marketplace/marketplace/b6d5093d-626e-41e9-b9e8-ff287bbe2c07/reference#endpoint__3 ABN: https://developer.abnamro.com/content/account-information Daar is weinig spannends aan. Authenticatie verloopt via oauth, en vervolgens kan de partij aangeven vanaf welke datum tot welke datum ze de transactie gegevens willen hebben, en krijgt dan in json formaat alle transacties die binnen die periode gedaan zijn terug. Maar je mag dus alleen RECHTSTREEKS gebruik van die API maken als je een vergunning van DNB hebt. == Overigens introduceert PSD2 wel ook nog andere regels, die wel betrekking hebben op payment providers. Zo is het bij credit card betalingen dadelijk niet voldoende dat je alleen de gegevens van de credit card verzamelt, maar wordt het gebruik van strong customer authentication zoals 3D secure verplicht. Mocht je huidige implementatie dat nu nog niet doen (bijv. als je Stripe gebruikt), dan kan het zijn dat je daar als webshop eigenaar nog wat aanpassingen voor moet doen.

Dan doneer je tevens 21% BTW over het arbeidsloon aan de belastingdienst?! Lijkt me niet handig.

Maar voor de ingredienten wordt toch alsnog BTW betaald, gezien je die wel factureert?

Niet? (Die 500 EUR eerst als omzet zien, om vervolgens cadeau te doen en af te trekken levert per saldo toch niets op?)

Maar goed, de overboekingen die de derde partij te zien krijgt, zijn enkel de transacties tussen jou en je energieleverancier. Bedenk wel dat als de derde partij daadwerkelijk een online boekhoudpakket is dat door je energieleverancier actief gebruikt wordt, jouw gegevens daar toch al in staan, want je NAW gegevens en hoeveel stroom je gebruikt zal ook wel in de boekhouding en op facturen staan. Zelfs als je contant zou betalen (bij een GWK kantoor ofzo), heeft de leverancier van het online boekhoud pakket je gegevens dan al. Het enige nieuwe gevaar is dus dat er tussenpartijen gebruikt gaan worden die voorheen niet gebruikt zouden worden. Dus als het energiebedrijf voorheen helemaal geen fan van online boekhouden was, maar de administratie op eigen systemen verwerkte. Maar nu wel een dergelijke tussenpartij moet gaan gebruiken omdat ze anders de transactie gegevens niet makkelijk kunnen uitlezen.

Het idee is dat je online dienstverleners -zoals een online boekhoudpakket of een online huishoudboekje- toestemming kan geven jouw transacties te mogen inzien. Vergelijkbaar met de online boekhoudpakket koppelingen die sommige banken nu ook al hebben, maar dan wel gestandardizeerd, en dus niet langer afhankelijk van of jouw bank wel kan samenwerken met de leverancier van jouw online boekhoudpakket. Er is alleen wel de regel dat -naast dat je als rekeninghouder toestemming moet geven- alleen dienstverleners die goedgekeurd zijn door de DNB (of een soortgelijke instantie uit een ander EU land), een dergelijke koppeling met de bank mogen opzetten. De bank wordt door PSD2 dus verplicht een hele mooie gestandardiseerde API voor het opvragen van rekeninginformatie beschikbaar te stellen. Alleen PSD2 schrijft voor dat nog steeds niet iedereen die API mag gebruiken. Bank <-> mijn eigen webwinkel software die draait op mijn eigen server mag dus niet. Want ik ben zelf nu eenmaal niet DNB approved... Maar: Bank <-> online boekhoudpakket <-> Mijn eigen webwinkel software is niet verboden. Op die tussenschakel zit ik echter niet zo te wachten. En heb niet het idee dat het veiligheid toevoegt, integendeel...

Vind het jammer dat je de rekeninggegevens alleen met bedrijven die onder toezicht van DNB staan kan delen. Zou graag willen dat mijn eigen webshop software de transacties van mijn eigen zakelijke bankrekening rechtstreeks bij mijn bank kon opvragen. Zodat als een klant met een handmatige bankoverschrijving betaald, ik dat makkelijker in mijn administratie kan verwerken. Maar nee, dat is bij de meeste banken nog steeds niet mogelijk. Dan blijft het moeilijk doen met CSV bestandjes, of verplicht je gegevens eerst delen met een tussenpartij die vervolgens wel een API aanbied waarmee je de transactiegegevens kan ophalen.

Hoezo dubbele kosten? Kost tegenwoordig toch niets extra's meer om telefoontjes te ontvangen in andere EU landen met een Nederlandse SIM? Kan wel zijn dat je met een buitenlands adres geen abonnement kan afsluiten, maar een prepaid kaartje zou geen probleem moeten zijn.

Ben wel benieuwd of de introductie van PSD2 nog voor verschuivingen gaat zorgen. Er mogen dan aan de klant geen meerkosten meer worden gerekend voor iDeal/credit card/Paypal betalingen. En bij credit card betalingen moet de transactie met strong customer authentication bevestigd worden, waardoor het kwa proces meer op iDeal gaat lijken.

Bedenk wel dat ze niet alleen concurrentie van Amazon hebben, maar ook bijvoorbeeld van normale webshops die Paypal accepteren. Daar krijgt de klant de retourkosten ook mee vergoed...

Zolang je daarnaast wel andere inkomsten hebt, zal dat wel meevallen. Er zijn een hoop "hobby ondernemers" zonder noemswaardige omzet. Maar aan de andere kant. Zal niet de eerste keer zijn dat de BD een student als windhapper aanmerkt. De meeste ‘windhappers’ vind je in Delft

Als ik het formulier van de business card van een grote bank erbij pak, dan kan ik als reden ook kiezen voor bijvoorbeeld: De goederen of diensten [ ] voldoen niet aan de opgegeven specificaties [ ] zijn beschadigd aangekomen [ ] zijn niet aangekomen of ontvangen Ja, ze verwachten wel dat je eerst contact met de verkoper opneemt. Maar dat lijkt me niet zo heel vreemd?!

Als er niet geleverd wordt wat er is besteld, dan kan de bank/credit card maatschappij de betaling gewoon terugboeken. De mogelijkheid tot het uitvoeren van een chargeback staat los van de aankoopverzekering, en kan doorgaans ook bij zakelijke transacties. Met een credit card afrekenen bied dan ook wel degelijk enige bescherming tegen juist de punten die je noemt.

Gaat het dan wellicht om een klant die met bitcoin heeft betaald? Zou wel verklaren waarom ze die informatie van een normale webwinkel willen hebben. Alle transacties die een bitcoin gebruiker doet zijn openbaar (staan in de blockchain) Als ze willen weten van wie een bepaald bitcoin adres is, en zien dat er eerder een transactie naar het adres van de webwinkel is gedaan, is het geen gekke stap om daar de gegevens op te vragen van de bestelling die op dat tijdstip is gedaan... Alleen doen ze dat dan wel onder een artikel dat daar niet voor is bedoeld.

In de praktijk levert niet iedere aanbieder gegevens aan bij de CIOT. Ze zijn pragmatisch en hebben niet zoveel zin om de duizenden providers die enkel hosting aanbieden (en geen normale Internet toegang) aan te sluiten. Maar zijn wel van mening dat het aanbieders van telecommunicatiediensten zijn (bieden immers ook e-mail enzo aan), en ik weet -als hostingprovider- dat de vorderingen die je vervolgens handmatig krijgt als ze de informatie niet in CIOT kunnen vinden, verwijzen naar dat artikel. Het is me niet helemaal duidelijk wat de TS levert. Ging er in eerste instantie vanuit dat de TS wel een hosting provider is en webwinkel op zijn klant sloeg. Maar je kan het inderdaad ook zo lezen dat de TS de webwinkel is.