View Issue Details

IDProjectCategoryView StatusLast Update
0006450Talermerchant backend API (C)public2021-08-24 16:23
ReporterFlorian Dold Assigned Tojonathanbuchanan  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Target Version0.8Fixed in Version0.8 
Summary0006450: merchant lib should parse taler_payto_uri, should be used in test cases
DescriptionIt looks like right now the taler_payto_uri is only used by the wallet, not by the merchant's own test cases. This makes it hard to tell if changes break anything.
TagsNo tags attached.



2020-08-04 22:04

developer   ~0016560

How should the merchant parse `taler_pay_uri`? Should I add a function that extracts all the parameters from the URI?

Florian Dold

2020-08-06 15:37

manager   ~0016563

I think this has two parts:

(1) Implementing a function that parses a taler://pay URI into its components (same will also be needed for taler://refund)
(2) Make the test cases use the taler://pay URI to execute the payment. TALER_TESTING_cmd_merchant_pay_order currently uses the order_id directly. Instead it should take the order_id (and the claim token and session id) from the taler://pay URI, just like the wallet does!

(Right now the test cases would pass even if the merchant screws up the taler://pay URI generation.)


2020-08-07 03:35

developer   ~0016569

I added a spec for these methods in b791a14..5560527.


2020-08-08 09:58

developer   ~0016572

I'm working on implementing it and I noticed that there can be certain situations where there is no way to distinguish between order_id and session_id according to the spec in

Suppose there is no claim token or ssid. If there is a segment seperated by '/' from the last segment, then the last segment could be a session_id or an order_id with the segments preceding it being part of merchant_prefix_path.

On a related note, what happens to 'c' and 'ssid' if there isn't a 'session_id'? It would make sense to omit the slash and append them to the order id.

Florian Dold

2020-08-08 11:39

manager   ~0016573

Let's look at the definition:


Effectively, the session_id is always present. But it can be the empty string, and in that case the path component of the URI ends with a slash! To get the session ID and order ID, you need to count from the back, as the merchant_prefix_path can consist of an arbitrary number of path segments.

The syntax follows the generic URI syntax: (see Section 3. Syntax Components). You can get the claim token (c) from the query string, which is simply between the first "?" and the fragment delimiter "#". Same for the ssid, which is just the whole fragment (if present)

Here's how the wallet does this parsing:


2020-08-08 21:51

developer   ~0016574

Ok, thanks for explaining!


2020-08-10 05:36

developer   ~0016578

Parser for pay URIs implemented in ef6fed1..119de8d (merchant.git).


2020-08-10 20:52

developer   ~0016585

Should the claim token always be returned with the pay_uri, or only when it the order is unclaimed? It currently does the latter.

On similar note, would it make sense to define a 'taler://claim' action and return that URI when the order is unclaimed?


2020-08-10 22:18

developer   ~0016586

Parser for refund URIs implemented in 119de8d..280bbb5 (merchant.git).

Christian Grothoff

2020-08-14 09:36

manager   ~0016604

Just given the URI, I don't see how the URI-parser can tell if the order is claimed or not. You should return the claim token if it is given in the URI (given that it is optional).


2020-08-20 07:12

developer   ~0016668

Parse/test refund URIs in 8d172853c1c7b1ca8d9dc31194c4e73e79499a80.

Issue History

Date Modified Username Field Change
2020-07-30 11:27 Florian Dold New Issue
2020-07-30 11:27 Florian Dold Status new => assigned
2020-07-30 11:27 Florian Dold Assigned To => jonathanbuchanan
2020-08-04 22:04 jonathanbuchanan Note Added: 0016560
2020-08-06 15:37 Florian Dold Note Added: 0016563
2020-08-07 03:35 jonathanbuchanan Note Added: 0016569
2020-08-08 09:58 jonathanbuchanan Note Added: 0016572
2020-08-08 11:39 Florian Dold Note Added: 0016573
2020-08-08 21:51 jonathanbuchanan Note Added: 0016574
2020-08-10 05:36 jonathanbuchanan Note Added: 0016578
2020-08-10 20:52 jonathanbuchanan Note Added: 0016585
2020-08-10 22:18 jonathanbuchanan Note Added: 0016586
2020-08-14 09:36 Christian Grothoff Note Added: 0016604
2020-08-20 07:12 jonathanbuchanan Status assigned => resolved
2020-08-20 07:12 jonathanbuchanan Resolution open => fixed
2020-08-20 07:12 jonathanbuchanan Note Added: 0016668
2020-10-03 14:09 Christian Grothoff Fixed in Version => 0.8
2021-08-24 16:23 Christian Grothoff Status resolved => closed