1. iWim
  2. RO Payments
  3. Wednesday, 29 October 2025
  4.  Subscribe via email
Hallo Roland,

Wanneer een klant een bestelling plaatst en wil afrekenen met een betaalmethode die gebruik maakt van RO Payments 9.1.0, dan blijft de website hangen.
De browser blijft laden zonder naar de betaalpagina te gaan.

De betaalpagina is Rabo Onlinekassa.

J! 5.4.0
VM 4.4.10
ROP 9.1.0 (8.5.0 is nog geïnstalleerd)
Rupostel OPC 2.0.457
PHP 8.2.27

Bestellingen komen wel in de bestellijst van VirtueMart en er komt een melding bij de transacties in RO Payments.
Ik zie geen link naar een logbestand...

Betaalmethodes die gebruik maken van 8.5.0 gaan wel door naar de betaalpagina.

Als je meer informatie nodig hebt, hoor ik dat graag.

Groeten,
Wim

PS:
Wat mij verder opviel is dat bij een betaling met 8.5.0 een ronddraaiend open cirkeltje bij de bevestigingsknop te zien is, maar bij een betaling met 9.1.0 staat er een teken dat dat niet bestaat. Maar mogelijk is dit een functie van Rupostel OPC...
Accepted Answer Pending Moderation
Hallo Wim,

Zojuist heb ik versie 9.2.0 uitgebracht, dat is wel een eerste stap die je kan doen, de update installeren.

Ik zie geen link naar een logbestand...
Het logbestand staat in de transactie lijst als laatste kolom en heeft als titel Toon Log. Aangezien de transactie wel in de lijst komt verwacht ik dat er sowieso een log is, wellicht minimaal maar dat moeten we dan zien.

Wat mij verder opviel is dat bij een betaling met 8.5.0 een ronddraaiend open cirkeltje bij de bevestigingsknop te zien is, maar bij een betaling met 9.1.0 staat er een teken dat dat niet bestaat. Maar mogelijk is dit een functie van Rupostel OPC...
Dat lijkt me iets te zijn van OPC want RO Payments doet niets met de bevestigingsknop. Eventueel kan het zijn dat er niets ronddraait omdat de betaling sowieso niet start. Krijg je wel een bevestigingspagina te zien of dat ook niet?
Kind regards,

RolandD

=========================
If you use our extensions, please post a rating and a review at the Joomla! Extension Directory
  1. more than a month ago
  2. RO Payments
  3. # 1
Accepted Answer Pending Moderation
Ik krijg geen bevestigingspagina.
Nadat ik op de bevestig-knop druk begint de browser te laden, maar de afreken-pagina blijft in beeld.

De link naar het log-bestand stond buiten beeld...
Er staat niet veel in:
[2025-10-29 09:00:37] Currency: EUR


Ik had 2 tests gedaan, beide logs hadden alleen deze melding.

Ik zal later kijken naar 9.2.0.
  1. more than a month ago
  2. RO Payments
  3. # 2
Accepted Answer Pending Moderation
Hi Wim,

Dat er weinig in staat, daar was ik al bang voor.

Nadat ik op de bevestig-knop druk begint de browser te laden, maar de afreken-pagina blijft in beeld.
Het lijkt erop dat de JavaScript een fout terug krijgt van de server en daardoor blijft hangen.

Ik zal later kijken naar 9.2.0.
Laat maar weten of het daar hetzelfde probleem optreed of dat die dan wel doorloopt. We kunnen dan verder kijken wat er aan de hand is.
Kind regards,

RolandD

=========================
If you use our extensions, please post a rating and a review at the Joomla! Extension Directory
  1. more than a month ago
  2. RO Payments
  3. # 3
Accepted Answer Pending Moderation
Hallo Roland,

Sorry dat het zolang duurde voor een antwoord. Tijd was even heel schaars.

RO Payments is inmiddels geüpdate naar 9.2.0.
(VirtueMart (4.6.4) en Joomla (5.4.1) zijn inmiddels ook weer geüpdate)

De pagina bleef nu niet hangen, maar kwam op een wit scherm.
Het adres was: /index.php?option=com_virtuemart&view=opc&controller=opc&task=checkout&nosef=1&virtuemart_product_id=1758&lang=nl&lang=nl

In de console van Firefox devtools stond alleen deze melding:
Deze pagina bevindt zich in de Quirks-modus. De pagina-indeling kan worden beïnvloed. Gebruik voor de standaardmodus ‘<!DOCTYPE html>’.


In het log van RO Payments stond dit:
[2025-11-26 14:44:28] Currency: EUR

[2025-11-26 14:44:28] The payment could not be created.

[2025-11-26 14:44:28] Notify URL: (...)/notify?pid=TIRA5qZAaXevJLc3vW5A9y7FzUYLHoeRUwPRo17sRnofGexJQz

[2025-11-26 14:44:28] Error Message: Data too long for column 'history' at row 1


Groeten,
Wim
  1. 2 weeks ago
  2. RO Payments
  3. # 4
Accepted Answer Pending Moderation
Hallo Wim,

Sorry dat het zolang duurde voor een antwoord. Tijd was even heel schaars.
Geen probleem hoor, ik ken het probleem :D

Error Message: Data too long for column 'history' at row 1
Dat is wel echt een probleem maar ik vraag me af hoe het komt dat er zoveel data in dat veld staat. Het is een tekst veld waar 65 535 tekens in kunnen. Dat is normaliter veel meer dan nodig is. Kan het zijn dat er qua orders opnieuw is begonnen met testen/werken?

Je kan het veld vergroten naar een LONGTEXT, dan kan er 4GB aan data in. Dan kan je wel zien wat voor data erin komt. Dat gaat dan met onderstaande SQL query. Eventueel kan je ook de logs tabel van RO Payments legen en de betaling starten om te zien of die dan wel doorloopt.

Hoor graag wat de bevindingen zijn.


ALTER TABLE X_ropayments_logs MODIFY COLUMN history LONGTEXT NOT NULL COMMENT 'History of payment request';
Kind regards,

RolandD

=========================
If you use our extensions, please post a rating and a review at the Joomla! Extension Directory
  1. 2 weeks ago
  2. RO Payments
  3. # 5
Accepted Answer Pending Moderation
Ik zal de SQL query proberen.

Ik weet niet precies wat je hiermee bedoeld:
Kan het zijn dat er qua orders opnieuw is begonnen met testen/werken?
  1. 2 weeks ago
  2. RO Payments
  3. # 6
Accepted Answer Pending Moderation
Okay, ik heb de SQL query doorgevoerd, maar de pagina gaat nog niet naar Rabo.
De logs waren wel uitgebreider.

Na de eerste test stond dit in het log:
[2025-12-01 14:23:44] Error creating payment: Client error: `GET https://betalen.rabobank.nl/omnikassa-api-sandbox/gatekeeper/refresh` resulted in a `403 Forbidden` response:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" (truncated...)
[body] <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Tijdelijk niet beschikbaar</title>
(...)html/css/jibberish(...)
<div class="bodytekst">
<p>
Op dit moment zijn verschillende diensten van de Rabobank niet beschikbaar. Onze excuses voor het ongemak.<br/>
Wij werken eraan om dit probleem zo spoedig mogelijk op te lossen.<br/></br>

<br/>Reference id: 0.8071002.1764599024.76ca24b5
</div>
(...)


Maar na wat kijken in het profiel van Rabo in ROP9.2 bleek dat de refresh token niet was overgenomen van de oude ROP8.5.
Die heb ik overgenomen in ROP9.2.

Bij het opnieuw proberen te bestellen kwam dit in het log
[2025-12-01 14:31:07] Currency: EUR

[2025-12-01 14:31:07] Error creating payment: Server error: `GET https://betalen.rabobank.nl/omnikassa-api-sandbox/gatekeeper/refresh` resulted in a `500 Internal Server Error` response:
{"code":"INTERNAL_SERVER_ERROR","message":"Can't find verifier for blahblahblah="}


[2025-12-01 14:31:07] The payment could not be created.

[2025-12-01 14:31:07] Notify URL: https://miniaturen.nl/notify?pid=blahblahblah

[2025-12-01 14:31:07] Error Message: Server error: `GET https://betalen.rabobank.nl/omnikassa-api-sandbox/gatekeeper/refresh` resulted in a `500 Internal Server Error` response:
{"code":"INTERNAL_SERVER_ERROR","message":"Can't find verifier for blahblahblah="}
  1. one week ago
  2. RO Payments
  3. # 7
Accepted Answer Pending Moderation
Hallo Wim,

OK, het uitbreiden van dat veld laat wel meer zien omdat je niet een verwacht bericht krijgt maar een complete webpagina. Dat past niet in het veld :D Het is in ieder geval wel duidelijk wat er aan de hand is.

Ik zie dat je nog op de sandbox bezig bent. Heb je getest met een iDEAL betaling? Zo ja, dan moet het eens bij de Rabobank nagevraagd worden wat er mis gaat in hun test omgeving. De foutmelding die je ziet komt uit het test systeem van de Rabobank.
Kind regards,

RolandD

=========================
If you use our extensions, please post a rating and a review at the Joomla! Extension Directory
  1. one week ago
  2. RO Payments
  3. # 8
Accepted Answer Pending Moderation
Hallo Roland,

SmartPay staat (al jaren) op productie en heeft ook altijd goed gewerkt.
En in het profiel van SmartPay staat Test Mode op Nee.

Ik heb een bestelling gedaan met Rupostel OPC uitgeschakeld, dus standaard VM cart. Ook die gaf dezelfde witte pagina en fout.
Ik heb de Test Mode op Ja gezet, om te kijken of de switch misschien zou helpen, maar dezelfde 500 melding in het log.


We hebben met de support van Rabo gebeld:

De technicus heeft zelf ook een test-bestelling gedaan. Hij bleef ook steken op de witte pagina die ik hierboven heb genoemd.
Hij gaf aan dat dat door een php fout komt (nu nog uitzoeken waar, maar of dat de oorzaak is...)


Hij heeft ook een post(?) test gedaan met een niet-werkend token/key naar de betaalpagina van rabo. Dan kwam standaard de 500 Internal Server Error.
Dus hij dacht dat het in de token/key zat die niet overeenkomt (met de sandbox).
Maar de gebruikte token/key is voor productie en die kloppen.

In het log wordt een tekenreeks meegestuurd die niet geverifieerd kan worden.
(In het log hierboven had ik die vervangen door blahblahblah=.)
De eerste en laatste 4 tekens zijn altijd:
n5Bx(...)oxE=
Dit is geen token/key van ons. Misschien herken je het.


Hij gaf ook als tip/optie om eens te kijken of jij een (tijdelijke) versie van ROP kon maken/sturen waarbij de sandbox link verwijderd is.
Wij gebruiken die toch niet. Mogelijk wordt de website dan wel naar de betaalpagina doorgestuurd.

Groeten,
Wim
  1. 4 days ago
  2. RO Payments
  3. # 9
Accepted Answer Pending Moderation
Hallo Wim,

Als je de sandbox niet gebruikt dan is de foutmelding wel te verklaren want die gaat namelijk wel naar de testomgeving. De sleutels die je hebt ingesteld zijn dan ook niet actief op de testomgeving.

Om de live omgeving te forceren kan je het volgende doen:

  1. Open het bestand components/com_ropayments/src/Psp/Onlinekassa/Onlinekassa.php
  2. Na regel 199 voeg je deze regel toe $url = Environment::PRODUCTION;
  3. Sla het bestand op
  4. Doe nogmaals de test
Mocht dit niet lukken dan kan ik je een aangepast bestand sturen.
Mocht dat werken, dan moet er eens gekeken worden waarom je geen juiste URL krijgt zoals het nu is, maar dit eerst maar eens proberen.

Hoor graag hoe het gaat.
Kind regards,

RolandD

=========================
If you use our extensions, please post a rating and a review at the Joomla! Extension Directory
  1. 4 days ago
  2. RO Payments
  3. # 10
Accepted Answer Pending Moderation
Hallo Roland,

Met jouw aanpassing wordt de klant wel doorgestuurd.

Nu moeten we dus nadenken waarom het op de 'oude' manier niet werkt.

Terwijl dat gebeurt:
Kan ik de verschillende betaalmethodes wel aanzetten, zodat klanten weer kunnen betalen met o.a. iDEAL?
Of moet ik daar nog even me wachten?

Groeten,
Wim
  1. 4 days ago
  2. RO Payments
  3. # 11
Accepted Answer Pending Moderation
Hallo Wim,

Dat de oude manier niet werkt ga ik eens testen om te zien of ik het kan reproduceren.

Kan ik de verschillende betaalmethodes wel aanzetten, zodat klanten weer kunnen betalen met o.a. iDEAL?
Je kan in VM de betaalmethodes aanmaken die je wil gebruiken. De klant kan die dan kiezen bij het afrekenen op de website.
Kind regards,

RolandD

=========================
If you use our extensions, please post a rating and a review at the Joomla! Extension Directory
  1. 2 days ago
  2. RO Payments
  3. # 12
  • Page :
  • 1


There are no replies made for this post yet.
Be one of the first to reply to this post!