Updated OpenAPI spec for voucher supplier, with examples more relevant to the first usecase (ooievaarspas AOW) - this YAML is also shared with PASS devs #60
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "feature/OVPAY-2545-vouchers"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@ -332,4 +307,3 @@},],}Voucher for a whole order:Is dit niet meer van toepassing?
Deze moest ik er van Paul uithalen voor PASS, en sowieso is complete winkelmand korting iets wat we nog niet echt besproken hadden toen ik dit maakte en wat ook niet formeel in scope is; de MVP is nu vooral bedoeld voor ooievaarspas.
Ik vind zeker prima om examples voor winkelmandkorting + kortingsbedrag op een specifiek product weer erin te hangen, maar voor nu is iig belangrijkst dat we de ooievaarspas case helemaal scherp hebben, want die wordt het eerst gebruikt
@ -321,4 +304,1 @@"value": "1980-06-31",},{"mandatoryCustomerDataItem":Waarom halen we deze eruit?
Voor ooievaarspas-product gaat PASS alleen PAD geboortedatum als claim meegeven, dus ooievaarspashouders kunnen straks met elk willekeurig emailadres inwisselen
@ -291,4 +290,1 @@"productId": 126,"productName": "HTM-30001","productDescription": "Regiovrij maand.","_links":Halen we die HATEOAS er bewust uit? Kan me voorstellen dat supplier niet per definitie dit endpoint aan kan roepen, dus dat het niet zoveel nut heeft.
Dit idd, in de TP versie lijkt het me wel nuttig, voor de supplier niet relevant (of zelfs niet toegestaan om te zien idd)
@ -15,3 +15,1 @@Get a list of all voucher definitions that the calling touch point is allowed to issue.Essentially, this means that only products that have active sellingPeriods for touch points within the sameretailer as the calling touch point are returned.Get a list of all voucher definitions that the calling touchpoint is allowed to issue.\WAAROM DIE BACKSLASH.
Is dit mooie-formatting shaming? :O
@ -29,3 +36,3 @@in: queryrequired: falsedescription: Filter the voucher definitions on a specific product id.description: Return a specific voucher definition by it's productId.its
@ -231,3 +234,3 @@in: queryrequired: falsedescription: The unique identifier of the product for which to retrieve all issued vouchers.description: Return only issued vouchers that were issued for the given voucher definition (by it's productId).*its
@ -437,1 +371,3 @@summary: Issue a voucher with prefilled voucher codeIssue a voucher and supply own voucher code:summary: Issue a voucher and supply own voucher codedescription: This allows the voucher supplier to supply its own voucher code, which can be useful if the suplier already has its own (internal or external) source for voucher codes. The supplied voucher code must be unique - if this code is already in use, the request will fail.*supplier
i no use AI, dis is proof
@maxmartens Voor consistentie misschien in de GET voucherdefinitions, de ooievaarspas prijs op 0 zetten, weerspiegelt de werkelijkheid ;) Voor de rest ziet de supplier kant er goed uit!