View Issue Details

IDProjectCategoryView StatusLast Update
0010615Talermerchant backendpublic2025-11-16 19:39
Reporterhtgoebel Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status confirmedResolutionopen 
Product Version1.0 
Target Version1.5 
Summary0010615: Add more data to MerchantOrderStatusResponse
DescriptionBased on the documentation as of today:
The MerchantOrderStatusResponse is missing relevant data and is missing data available in OrderHistoryEntry.
Of course, including data about payment in UnpaidResponse or about refunds in the ClaimedResponse does not make much sense. Anyhow, some data is only available in the UnpaidResponse later. Thus is one does not collect data while the payment is "unpaid", one will not be able to retrieve it as soon as some wallet claimed or paid.

Also some data is only available in the non-public URL and some data is not available at all.

This information might be relevant, since e.g. a ERP system might not set deadlines but might rely on the deadlines calculated by the backend - and act based on these.
Additional InformationExpected: All MerchantOrderStatusResponse include
- the data from the non-public response
- pay_deadline, refund_deadline, wire_deadline
- timestamp/creation_time:
- summary
- order_id
- total_amount
- (already_paid_order_id, already_paid_fulfillment_url)

(You might have a better idea of this.)
TagsNo tags attached.

Activities

Bohdan

2025-11-15 12:04

developer   ~0026459

Firstly, the get orders-id is non-public (you need a token with orders-read permission), so this
"- the data from the non-public response". I really don't get it, I assume you refer to data obtained by wallet through post /claim, but still...

Honestly, as a person who implements module for Dolibarr, who also did it for SAP, I don't really get what your problem is.

I mean, theoretically, it is not easy to get the info about the order if it was created on the Taler side, and you have to make a hell lot of assumptions to get it to ERP(if you didn't set up webhooks)... But I assume/hope that only I am crazy enough to proceed with this case.

In case you have an order in Tryton, you have all the data inside. And then you just need to track the status of the order.

So, sorry, but I really don't get what this bug is about

Christian Grothoff

2025-11-15 15:58

manager   ~0026462

I read Hartmut's request as being about the GET /private/orders/$ID endpoint, not the public one.
And yes, I think he's right, we should return much more data there.

htgoebel

2025-11-16 19:00

developer   ~0026492

Sorry for being not precise enough. I'm referring to the API endpoints described in "1.4.11.2. Inspecting orders":
   GET [/instances/$INSTANCE]/private/orders
and
   GET [/instances/$INSTANCE]/private/orders/$ORDER_ID

1. Using these endpoints, I have not found any way retrieve any of the deadlines of an UNPAID order.
    The use-case: The shop/ERP creates an order without providing any deadline or delays, but wants to learn about the deadlines. E.g. to purge records from its own database or to inform the user about the pay deadline.
    This is actually true in the SPA: While for claimed and paid orders there is a nice time-line, for unpaid orders the is not even the pay deadline.

2. The backend offers the neat feature of replacing ${ORDER_ID} within the fulfillment URL. Anyhow, this url is not returned when querying UNPAID orders.

3. Symmetry: I'm not an expert in REST APIs, anyhow I'd expect a GET request to provide the information I've send with the POST request.
 
4. Symmetry: The OrderHistoryEntry returns information not available in the CheckPaymentUnpaidResponse, see examples. Of course, one can discuss whether the row_id is actually required for an unpaid response, but why does it exist in the history entry then?

OrderHistoryEntry:
{'orders': [{'amount': 'KUDOS:1',
             'order_id': '2025.320-02AAKWRASBA7J',
             'paid': False,
             'refundable': False,
             'row_id': 31678,
             'summary': 'Test',
             'timestamp': {'t_s': 1763315504}},

CheckPaymentUnpaidResponse:
{'creation_time': {'t_s': 1763315504},
  'order_status': 'unpaid',
  'order_status_url': 'https://backend.demo.taler.net/instances/sandbox/orders/2025.320-02AAKWRASBA7J?token=20V8C7RED29GPJ97YRQ0444SPC',
  'summary': 'Test',
  'taler_pay_uri': 'taler://pay/backend.demo.taler.net/instances/sandbox/2025.320-02AAKWRASBA7J/?c=20V8C7RED29GPJ97YRQ0444SPC',
  'total_amount': 'KUDOS:1'},

Bohdan

2025-11-16 19:39

developer   ~0026493

1. Timestamp + default payment time (per /private endpoint). Or save the PostOrderResponse... While I agree, it might be nice to add pay_deadline there...

2. No idea for use-case when you really need it for processing, before the user has actually paid/claimed the order... yet available in the public get /order-id, so it is designed to be available for wallets but not merchants. Does it really belong to UNPAID by design is up to Christian.

3. I am not aware of any RFC that will support your expectation; nearly all data will be available as soon as the wallet claims the order through contract terms.

4. I guess row_id is for pagination, here quote from the docs:

offset – Optional. Starting row_id for an iteration. Since protocol v12.

So yep, theoretically adding new fields to the answer is not a huge thing(and quite quick), and wouldn't break communication, yet it is really the question, does it really make sense (e.g., the data is unavailable right now at all, or each time you have to call 2-3+ endpoints to gather the data you need). So, just adding data inside responses, because we simply can, is not the way to go, in my opinion.

Still, somehow the SPA is functioning with these endpoints...

Issue History

Date Modified Username Field Change
2025-11-14 22:50 htgoebel New Issue
2025-11-15 00:51 Christian Grothoff Severity minor => feature
2025-11-15 12:04 Bohdan Note Added: 0026459
2025-11-15 15:58 Christian Grothoff Note Added: 0026462
2025-11-15 15:58 Christian Grothoff Status new => confirmed
2025-11-15 15:58 Christian Grothoff Product Version => 1.0
2025-11-15 15:58 Christian Grothoff Target Version => 1.5
2025-11-16 19:00 htgoebel Note Added: 0026492
2025-11-16 19:39 Bohdan Note Added: 0026493