Categorieën
E-commerce

Verwijder de termen “creditcards” en “debitcards” op je betaalpagina

In de Buckaroo partner nieuwsbrief met onderwerp “Partner nieuwsbrief Q1” verstuurd op 11 januari 2024 had Buckaroo een item “Communicatie Mastercard en Visa” opgenomen met de volgende inhoud:

Communicatie Mastercard en Visa

Door het invoeren van nieuwe regels vanuit Mastercard en Visa is het niet meer toegestaan om de termen “creditcards” of “debitcards” te gebruiken als betaalmogelijkheid op een betaalpagina. Dit specifieke woord moet vervangen worden door Cards. Daarnaast moeten de juiste (actuele) logo’s van Mastercard en Visa worden gebruikt. Wij hebben dit in al onze plug-ins standaard verwerkt. Klanten die de Buckaroo plug-ins gebruiken hoeven dit niet aan te passen, maar wanneer ze niet gebruikmaken van onze plug-ins moeten ze dit zelf aanpassen.

Buckaroo

Op de achterliggende pagina “Verwijder de termen “creditcards” en “debitcards” op uw betaalpagina” geeft Buckaroo uitleg over deze nieuwe regels vanuit Mastercard en Visa:

Verwijder de termen “creditcards” en “debitcards” op uw betaalpagina

Door het invoeren van nieuwe regels vanuit Mastercard en Visa is het niet meer toegestaan om de termen “creditcards” of “debitcards” te gebruiken als betaalmogelijkheid op uw betaalpagina. Dit specifieke woord moet vervangen worden door de term “Cards”. Daarnaast moeten de juiste (actuele) logo’s van Mastercard en Visa worden gebruikt. Wij hebben dit in principe in al onze Plug-ins standaard verwerkt. Als u onze Buckaroo plug-ins gebruikt hoeft u dit dus niet zelf aan te passen.

Er is een uitzondering. Wanneer u het veld “Front-end Label” heeft aangepast dan dient u dit zelf aan te passen. Hieronder vindt u een voorbeeld hoe dit eruitziet bij WooCommerce. U kunt dit veld zelf handmatig aanpassen.

Gebruikt u geen Buckaroo Plugins?

Wanneer u zelf uw betaalpagina heeft ingericht en daarbij apps heeft gebruikt die niet van Buckaroo zijn dient u dit zelf aan te passen. Wij kunnen dit dan niet voor u doen. Heeft u het beheer van uw website uitbesteed en weet u niet zeker welke plug-ins u gebruikt? Neem dan contact op met uw websitebeheerder om dit te controleren en verder te regelen.

Waarom is deze regel opgesteld?

De naam creditcard en of debitcard wordt nu soms nog gebruikt als een soort verzamelterm voor meerdere betaalmogelijkheden (bijv. visa, credit en debit). Dit mag niet meer, omdat dit niet klopt. De term “cards” mag hiervoor wel gebruikt worden.

Controle

Mastercard en Visa gaan controles uitvoeren om te kijken of dat de termen creditcard en debitcard niet meer gebruikt worden op betaalpagina’s. Wanneer u deze termen nog in uw checkout heeft staan kunt u hierop worden aangesproken en worden er vervolgacties uitgevoerd als u dit negeert.

Buckaroo

Bij Pronamic waren we wel benieuwd naar de originele berichtgeving hierover van Mastercard en/of Visa. Op de websites van Mastercard en Visa konden we hier echter geen informatie over vinden.

Een aantal weken later kregen we bericht van een Adyen-gebruiker die ook bezig was met de naamgeving van de creditcard betaalmethode. Adyen heeft op de pagina “Co-badged cards compliance” hier ook het één en andere over vermeld:

Do not discriminate between card products

If you accept both credit and debit cards, to be compliant, your checkout must have a cards section that refers to both debit and credit cards. You cannot present only a credit card section. The following are examples of compliant labels for the card payments section in your checkout form:

  • Cards
  • Card payment
Adyen

Deze richtlijn komt blijkbaar voort uit de EU IFR-verordening 2015/751 artikel 8. Dat zal waarschijnlijk ook de reden zijn waarom organisaties zoals Mastercard en Visa aansturen op het vermijden van de termen “creditcards” en “debitcards”.

We hadden via de “Mollie Developer Community” Discord-server ook nog geïnformeerd naar het standpunt van Mollie in deze. Daar gaf een productmanager van Mollie het volgende aan:

In NL people are still used to Credit Card, since that was the only card you could use for online payments. But this will change with all the banks moving from Maestro/VPay to MasterCard Debit or Visa Debit.

In other countries (like the UK), it was already possible to make online payments with a debit card. So this is why you may see “Cards” for UK localization, but maybe still “Credit Card” for Dutch. But “Cards” is the most future proof 😉
Also, a recommended practice is to leverage our Methods API to get the correct name. You add a locale property so it will be translated. That way you should always be good.

Mollie

Dit alles heeft waarschijnlijk ook weer te maken met het Project DCA (Debit Card Acceptatie).

Er lijkt wat dat betreft zeker het één en andere te veranderen op het gebied van betaalpassen.

Categorieën
WooCommerce

WooCommerce order referrer en order attribution tracking

Een aantal maanden geleden kwam ik op het idee om per WooCommerce-bestelling de ‘referrer’ bij te gaan houden. Op die manier zou ik per bestelling kunnen bekijken vanaf welke website de koper op mijn webwinkel is gekomen en vervolgens een bestelling heeft geplaatst. Voor dit idee heb ik uiteindelijk de experimentele plugin “Pronamic Order Referrer for WooCommerce” geschreven. En nu lijkt het er op dat WooCommerce een vergelijkbare functionaliteit heeft geïntroduceerd. Toevallig zag ik vorige week namelijk een bericht van James Kemp, een WooCommerce productleider, op X over een nieuwe ‘order attribution tracking’ functionaliteit in WooCommerce:

Meer informatie over WooCommerce order attribution tracking is te lezen op: https://woo.com/document/order-attribution-tracking/ 🎉. Deze functionaliteit is toegevoegd vanaf WooCommerce versie 8.5.0, gelanceerd op dinsdag 9 januari 2024. Het originele ‘pull request’ voor het toevoegen van deze functionaliteit dateert al vanaf 12 augustus 2023: https://github.com/woocommerce/woocommerce/pull/39701.

Categorieën
iDEAL

Aantal iDEAL-transacties en totaal bedragen volgens het CBS t/m oktober 2024

Het Centraal Bureau voor de Statistiek (CBS) publiceerde op 1 december 2023 weer een tabel met betalingstransacties naar betaalmethode per maand. In het bericht “Betalingstransacties naar betaalmethode, aantallen en bedragen per maand” kan het Excel-document met de details gedownload worden. Voor iDEAL staat het er als volgt voor.

20192020202120222023

aantalaantalaantalaantalaantal

× 1000× 1000× 1000× 1000× 1000






Januari52.30063.70096.800101.660109.408
Februari45.90058.20088.30088.25198.685
Maart50.60062.80096.900100.206111.149
April50.40069.40093.50098.168108.449
Mei56.80075.80096.000106.171117.559
Juni56.10076.20095.800104.643115.533
Juli56.90077.70092.600103.210116.945
Augustus54.10074.80089.20097.744109.665
September56.80073.70089.200100.779111.175
Oktober59.70081.10096.100105.855118.212
November62.70084.100101.100112.556
December64.50092.900107.313113.507
Aantal betalingstransacties met iDEAL per maand
20192020202120222023

mln euromln euromln euromln euromln euro






Januari4.2945.4918.2579.64010.457
Februari3.5294.7047.5287.5828.729
Maart3.9525.8198.3238.67710.158
April4.0015.0128.3638.3369.120
Mei4.6605.4439.1379.58610.755
Juni4.4215.6828.1179.23910.909
Juli4.5405.8267.5548.77710.531
Augustus4.2715.3797.4278.4109.928
September4.4295.3537.3978.4629.468
Oktober4.5675.8477.9188.80710.810
November4.8746.7128.9679.581
December5.8178.1819.06010.233
Totaal bedrag betalingstransacties met iDEAL per maand

Daarmee lijkt oktober 2023 in de boeken te gaan als de meest succesvolle maand voor de iDEAL-betaalmethode. In totaal ruim 118.212.000 iDEAL-transacties met een totaalbedrag van € 10.810.000.000, dat is een gemiddelde van ~ € 91,45 per iDEAL-transactie.

Black Friday heeft miljoenen transacties opgeleverd: winkels en online shops verkochten dit jaar meer dan ooit. Volgens betaalplatform iDEAL is een recordaantal van 7,1 miljoen betalingen verricht.

NU.nl – https://www.nu.nl/economie/6291292/winkels-verkochten-opnieuw-meer-dan-ooit-tijdens-black-friday.html
Categorieën
iDEAL

Aantal iDEAL-transacties en totaal bedragen volgens het CBS

Het Centraal Bureau voor de Statistiek (CBS) publiceerde op 24 oktober 2023 weer een tabel met betalingstransacties naar betaalmethode per maand. In het bericht “Betalingstransacties naar betaalmethode, aantallen en bedragen per maand” kan het Excel-document met de details gedownload worden. Voor iDEAL staat het er als volgt voor.

20192020202120222023

aantalaantalaantalaantalaantal

× 1000× 1000× 1000× 1000× 1000






Januari52.30063.70096.800101.660109.408
Februari45.90058.20088.30088.25198.685
Maart50.60062.80096.900100.206111.149
April50.40069.40093.50098.168108.449
Mei56.80075.80096.000106.171117.559
Juni56.10076.20095.800104.643115.533
Juli56.90077.70092.600103.210116.945
Augustus54.10074.80089.20097.744109.665
September56.80073.70089.200100.779111.175
Oktober59.70081.10096.100105.855
November62.70084.100101.100112.556
December64.50092.900107.313113.507
Aantal betalingstransacties met iDEAL per maand
20192020202120222023

mln euromln euromln euromln euromln euro






Januari4.2945.4918.2579.64010.457
Februari3.5294.7047.5287.5828.729
Maart3.9525.8198.3238.67710.158
April4.0015.0128.3638.3369.120
Mei4.6605.4439.1379.58610.755
Juni4.4215.6828.1179.23910.909
Juli4.5405.8267.5548.77710.531
Augustus4.2715.3797.4278.4109.928
September4.4295.3537.3978.4629.468
Oktober4.5675.8477.9188.807
November4.8746.7128.9679.581
December5.8178.1819.06010.233
Totaal bedrag betalingstransacties met iDEAL per maand

Volgens de laatste berichten moet november 2023 de cijfers hierboven weer ruim gaan overtreffen:

Black Friday heeft miljoenen transacties opgeleverd: winkels en online shops verkochten dit jaar meer dan ooit. Volgens betaalplatform iDEAL is een recordaantal van 7,1 miljoen betalingen verricht.

NU.nl – https://www.nu.nl/economie/6291292/winkels-verkochten-opnieuw-meer-dan-ooit-tijdens-black-friday.html
Categorieën
Hosting

SiteGround Access Logs analyseren met GoAccess deel 2

In 2021 schreef ik al eens het bericht “SiteGround Access Logs analyseren met GoAccess”, in dit bericht een vervolg met enkele verbeteringen. SiteGround houdt de access logs per dag bij in de volgende map: /home/customer/www/example.com/logs. De bestanden zijn ingepakt en hebben de volgende notatie: example.com-2023-07-01.gz. Voor het analyseren van de access logs is het vaak handig om de logs van meerdere dagen te gebruiken. In dit bericht is te lezen hoe dat eenvoudig te doen is.

Categorieën
E-commerce iDEAL WooCommerce WordPress

Self-billing factuur van Mollie, Buckaroo, etc.

Omdat we bij Pronamic betaaloplossingen ontwikkelen voor payment providers zoals Mollie, Buckaroo, Pay.nl, etc. zijn we vaak partner van deze organisaties. In sommige gevallen krijgen we commissie voor succesvolle betalingen die via de Pronamic Pay plugin zijn opgestart. De payment providers betalen ons maandelijks of per kwartaal de opgebouwde commissie uit. Voor de boekhouding ontvangen we dan vaak een zogenaamde self-billing factuur. Waar voorheen nog wel eens creditnota’s werden verstuurd lijken de payment providers nu over te stappen naar self-billing facturen. Ik was tot vandaag niet heel bewust van dit concept. In dit bericht wat meer informatie over het self-billing principe.

Categorieën
Gravity Forms PHP WordPress

Koppeling Realworks Wonen API met WordPress en Gravity Forms

Voor een makelaar hebben we een koppeling gemaakt met de Realworks Wonen API en Gravity Forms. Woningzoekers kunnen op de website van de makelaar een Gravity Forms formulier invullen met contactgegevens en woonwensen. Deze gegevens worden vervolgens automatisch doorgezet naar Realworks. Daarmee hoeft de makelaar de formulier inzendingen niet meer handmatig in Realworks te zetten.

Categorieën
WordPress

WordPress bedrijven op GitHub

Categorieën
Geen categorie

Developer Roadmaps

https://roadmap.sh/

Categorieën
Geen categorie

Programmeren in je moedertaal of in het Engels?

Bij Pronamic hebben we als richtlijn dat we alles strict in het Engels programmeren. Stagiairs leren we daarom ook altijd om in het Engels te programmeren. Toch zijn er op internet ook vele voorbeelden te vinden waarin Nederlandse naamgeving wordt gebruikt in de code. Waarom heeft Engels dan bij ons de voorkeur? Ik ben voor de aardigheid eens op zoek gegaan naar goede argumenten. Al snel kwam ik een artikel tegen uit het boek “Het beste van PHP en MySQL“.

Engels of Nederlands

Amerikaans Engels is de voertaal onder programmeurs. Ook de meeste PHP-ontwikkelaars gebruiken Engels. Als je echter PHP-script alleen voor jezelf schrijft of als je in een team met alleen Hollanders en Vlamingen werkt, zijn er goede redenen om Nederlands te gebruiken.

Wanneer je Nederlands gebruikt voor alle namen die je zelf kunt kiezen, wordt broncode beter leesbaar. Het verschillen tussen Engelstalige termen uit PHP en zelfgekozen namen in dan direct zichtbaar. Dat is de reden waarom ik in dit boek vaker Nederlands gebruik dan Engels: het maakt de voorbeelden veel duidelijker als PHP nieuw voor je is.

De kans op naamconflicten neemt drastisch af als je Nederlands gebruikt. Als je Engels gebruikt voor bijvoorbeeld een functie die je zelf definieert, bestaat altijd het risico dat je per ongeluk een bestaande PHP-functie gebruikt. Naamconflicten kunnen ook voorkomen met andere talen die je in PHP gebruikt: HTML, CSS, SQL, HTPT, MIME, XML enzovoort gebruiken allemaal Engels.

Natuurlijk moet je niet overdreven vasthouden aan het Nederlands. Hoewel databank en gegevensbank foutloos Nederlands zijn, zeggen en schrijven ontwikkelaars altijd database. Het Nederlands kent al helemaal geen bruikbaar synoniem van query. In zulke gevallen kun je naamconflicten voorkomen door verschillende woorden of een samenstelling met Nederlands te gebruiken. Maak dan van $database en $query bijvoorbeeld $database_met_producten en $selectiequery.

Ward van der Put

In een boek zoals deze is het denk ik ook prima om Nederlandse code voorbeelden te gebruiken. Lezers kunnen op die manier waarschijnlijk sneller zaken herkennen. Het argument om Nederlands te gebruiken om naamconflicten te voorkomen vind ik wat minder sterk. Voor dat probleem zijn er in PHP denk ik namespaces geïntroduceerd.

Al met al nog niet hele sterke argumenten om wel of niet in het Engels of Nederlands te programmeren. Ik ben daarom verder gaan zoeken en kwam o.a. de volgende vragen / topics tegen:

Velen geven aan dat Engels de voorkeur heeft, maar om programmeren te leren je moedertaal wel fijn kan zijn.

DomQ (een Fransman) noemde nog wel de volgende aandachtspunten:

• I speak the language that the target audience will most likely understand. When coding open-source software with a global ambition, I use English. For less widely useful stuff (for instance, my Emacs configuration file), I might use French.

• I acknowledge the fact that not everyone will master English. In that perspective, using my mother tongue might actually make my code more accessible instead of less (in the example above, nobody cares about an umpteenth .emacs, except if it happens to be written in a language that they understand).

• Better to write good French than bad English. I actively discourage my subordinates from writing half-assed English especially where concision matters, eg in docstrings and version control commit messages.

https://softwareengineering.stackexchange.com/a/1764

Mattias Kihlström (een Zweed) noemde volgende argumenten om Engels te gebruiken:

• Allmost all programming languages I have ever used have been written in English (mixing languages would make the code harder to read for me)

• Most popular frameworks and third party extension are written in English (again, mixing languages would only be a distraction)

• Swedish characters (åäö) are usually not allowed when naming variables and functions

• If the other team members are from different countries we can still collaborate

• If I need support from a platform vendor it is is much easier for them to help me if they can understand my code

• It is easier to outsource support

https://softwareengineering.stackexchange.com/a/1687

Ik sluit me persoonlijk aan bij de argumenten van Mattias, dat zijn denk ik ook de redenen waarom we bij Pronamic in het Engels programmeren.

Mocht je zelf ook nog goede redenen hebben om in het Engels of juist in het Nederlands te programmeren dan hoor ik ze graag. Laat daarom gerust een reactie achter.