PaymentID vanuit Ogone meesturen als extraElement via ZaakDMS

[olenitsj]

Conclusions on how we'll approach this: https://github.com/open-formulieren/open-forms/issues/4380#issuecomment-2247845001

Thema / Theme

API

Omschrijving / Description

Context: Een formulier waar betalingen via ideal/creditcard plaats vinden(Ogone).

Bij het creëren van een zaak via ZaakDMS(stuf-zds) willen wij de PaymentId als een extraElement mee opgestuurd krijgen.

Dit is nodig zodat wij de paymentID i.c.m een product code aan SAP door kunnen geven voor het registeren van een verkoop.

De alternatief die wij hebben, is gebaseerd op de referentie die door openforms wordt meegestuurd richting ogone, de betalingID op te zoeken via de OgoneAPI, maar dit is erg omslachtig als de gegevens direct na het voltooien van betaling al bekend zijn bij openforms.

Added value / Toegevoegde waarde

Geen extra koppeling met ogone nodig voor het ophalen van de paymentId op basis van een door openforms mee gegeven referentie.

Aanvullende opmerkingen / Additional context

No response

[olenitsj]

We concluderen net, dat andere velden, zoals: bedrag/prijs. Niet via ZaakDMS mee wordt getuurd. De scope van deze story wordt iets groter dan initieel gedacht.

We moeten namelijk ook de volgende velden mee krijgen: Payment.completed (zou altijd true moeten zijn) Payment.amount Payment.public_order_ids (OF- id die mee word gestuurd als ref naar ogone van uit openforms) PaymentId (de id welke terug wordt gestuurd door ogone, is anders dan de OF- ref)

[joeribekker]

We concluderen net, dat andere velden, zoals: bedrag/prijs. Niet via ZaakDMS mee wordt getuurd. De scope van deze story wordt iets groter dan initieel gedacht.

We moeten namelijk ook de volgende velden mee krijgen: Payment.completed (zou altijd true moeten zijn) Payment.amount Payment.public_order_ids (OF- id die mee word gestuurd als ref naar ogone van uit openforms) PaymentId (de id welke terug wordt gestuurd door ogone, is anders dan de OF- ref)

We already sent the Payment status as part of the default Zaak-attributes. No need for this one right? We can however include the other fields:

• amount - extraElement
• public_order_ids - zaak kenmerken?
• paymentId - extraElement

Estimate: 3 days

[CMasselink]

We already sent the Payment status as part of the default Zaak-attributes. No need for this one right? We can however include the other fields:

You are right, there is no need for an extra payment status since it is part of the default zaak-attributes.

amount - extraElement public_order_ids - zaak kenmerken? paymentId - extraElement

public_order_ids can be an extraElement as well.

[alexvdL-utrecht]

Hierbij goedkeuring voor deze opdracht voor de gemeente Utrecht. @joeribekker Hebben jullie hiervoor ruimte? Onze wens is dat dit half augustus beschikbaar is voor acceptatie. Inhoudelijke aansturing door @olenitsj .

[joeribekker]

Aangegeven dat volgende release eind september is. Alex gaat intern kijken of dat kan.

[alexvdL-utrecht]

@joeribekker Utrecht is voornemens om in de eerste week van October, OO's te migreren waar ook formulieren met betalingen gebruikt worden. Midden augustus in acceptatie is al erg krap. Aangezien wij de koppeling ook nog moeten, bouwen, testen en live brengen en ook de migratie team moet de ruimte krijgen om hun migratie scripts te bouwen, testen en accepteren gerelateerd aan betalingen. Daarom het verzoek om hiervoor toch een 2.7.x uit te brengen. Kan deze bijvoorbeeld mee in 2.7.1? Of zijn we daarvoor al te laat?

[joeribekker]

@alexvdL-utrecht dit is geen patch, dit is een feature. Het kan dus niet zomaar mee in een patch release omdat het gedrag anders is. We kunnen het als extensie doen hopelijk als tijdelijke oplossing, dat kost extra tijd. In 2.8 zit het dan zonder extensie.

Lingo: OO=Organisatie Onderdelen?

[joeribekker]

@alexvdL-utrecht @CMasselink kunnen jullie bevestigen dat dit om extraElementen in een StUF-ZDS bericht gaat, vanuit Open Formulieren (zoals @olenitsj aangeeft)? Wij hadden zelf namelijk gedacht dat het ging om een attribuut in het Object, dat jullie ESB dan vertaalt naar een StUF-bericht?

[sergei-maertens]

Notes from the refinement with the stakeholder:

• Similarly to the Objects API template context, for StUF-ZDS registration backend we need access to the payment (context) variables: completed (True/False), amount (price of submission), public_order_ids (payment references sent to/available in Ogone)
• Additionally, the Ogone paymentid should be exposed too (also add to objects API for 2.8 for consistency!). This is a bit trickier because we need a generic mechanism for this first, but it all sounds logical and natural to me. The existing SAP processes require this input and cannot be adapted (at this time).

About the timeline and distribution of the feature:

• We stick to our original 2.8 release schedule and semantic versioning policy - these additional features will not be included in a patch release. We will develop them as part of the 2.8 release cycle
• However, to accommodate the needs of Utrecht, we will also distribute the feature as an extension that can be included in an Open Forms Docker image build. We will publish this build to Docker Hub using our automated CI pipeline. The image reference will take the form of openformulieren/open-forms:utrecht-2.7.y.
• The core and the extension adhere to our regular quality control: unit tests, automated testing/publication/distribution etc. There is a small risk that the extension itself breaks something due to unforeseen factors. This should be checked and prevented through Utrecht's on DTAP environment progression to catch any issues before they hit production.
• Our regular patching schedule applies - once we have a new patch for core, an automatic build for this patch release + the extension will be created and published.
• Note that this is different from a fork or separate branch that gets outdated because of the above.

I'm stretching up Joeri's estimate of 3 days to 6 days because of the additional coordination required and operational overhead.

For development:

Possibly creating a registration extension and subclassing the existing StufZDSRegistration is the easiest route:

• we can override the registration methods to modify the behaviour
• we can extend the options serializer to offer a template (?) field for payment information that will be included in extraElementen. This should play well-enough with the generic configuration UI setup through react-json-schema-form.
• once transitioning starts to 2.8, we can then apply a data migration to change the registration plugin id from stuf-zds-create-zaak:ext-utrecht to the regular stuf-zds-create-zaak, or run a database query for this (TBD).
• the payment stuff/references is still a bit of an unknown how we can address this, but possibly we can also extend/override the Ogone plugin.

[sergei-maertens]

@stevenbal I created https://github.com/open-formulieren/open-forms-ext-stuf-zds-payments, you can follow the documentation to bootstrap the extension, and take a look at existing extensions in our organization.

[sergei-maertens]

@olenitsj de image tag utrecht-zds-2.7.x is vanaf nu beschikbaar op Docker Hub (zie https://hub.docker.com/r/openformulieren/open-forms/tags), dus jullie kunnen dit deployen en uittesten op jullie O/T/A omgevingen. Deze is ietsje nieuwer dan 2.7.4.

Er komt volgens onze reguliere release cycle ook nog een tag utrecht-zds-2.7.5 - er is nog geen concrete datum bekend hiervoor, maar dit zou binnen de 4 weken moeten gebeuren.

[olenitsj]

@sergei-maertens, Do we need to configure something to return the payment attributes in the stuf ZDS creerzaak soap measage?

Right now, we have the 2.7.x (Gemeente Utrecht extension) version installed, but we don't see any of the payment information.

[sergei-maertens]

Hoi @olenitsj - je moet inderdaad een mapping instellen. Wij hebben hiervoor een default ingesteld, maar mogelijks ontbreekt die bij jullie. Helaas kan ik momenteel niet bij onze testomgeving voor een screenshot.

Kan je een Taiga ticket aanmaken zodat een support-medewerker dit kan opvolgen? Als je linkje naar dit issue opneemt, dan vinden we de weg!

[sergei-maertens]

@olenitsj ik heb weer toegang - hierbij een screenshot van de default-instellingen:

Dit resulteert in de extraElementen met naam payment_completed, payment_amount, payment_public_order_ids.0 en provider_payment_ids.0 indien er 1 betaling was bij de formulierinzending.

[olenitsj]

Done https://taiga.maykinmedia.nl/project/gemeente-utrecht-common-ground-platform/issue/283