View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005099 | Taler | other | public | 2017-06-29 18:26 | 2018-04-15 20:34 |
| Reporter | Florian Dold | Assigned To | Florian Dold | ||
| Priority | urgent | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.5 | Fixed in Version | 0.5 | ||
| Summary | 0005099: spec and implement "user tipping" from merchant website to wallet | ||||
| Description | The use case here is to casually award the user for certain things. The tip received by the wallet is not associated with any contract terms. After announcing the user tip via 402 Payment Required, the wallet will generate planchets for the announced amount (and for an exchange determined by the merchant). These planchets are then sent to the merchant, and the "TALER_WithdrawRequestPS" signature is added. The customer can then do the final part of the withdraw at the exchange. We assume that the merchant has a fixed reserve key pair that coins are withdrawn from. | ||||
| Tags | No tags attached. | ||||
| parent of | 0005169 | closed | Marcello Stanisci | bank Web interface should allow wire transfers between accounts *without* Taler |
|
|
How do we handle authorizing tipping? Should it work like with refunds, where the frontend is stateless and authorizes a tip for a "tipping reason" (such as user_fdold91_signup_bonus), and then there is a separate URL (containing some unguessable hash) where the tip can be "picked up"? In this case the backend would allow at most one tip per "tipping reason". Or should the frontend always make the decision on the fly whether to sign tipping coins from the wallet? The former sounds more robust, is a familiar pattern (from refunds) and guards against certain mistakes that could be made in the merchant frontend. |
|
|
Unlike refunds, I don't see a real-world case where a human would provide a tipping reason for "user tipping", so I think this should be a pure frontend-request without any back-office state (or even a "reason" code). The main protection for the merchant is that they can limit how much they put into the reserve. |
|
|
1d87911..412a362 updates the merchant backend specification. I could not find the 402 Payment Required specification anywhere, so I could not update that. Florian, where in our documentation are the 402-headers currently documented? |
|
|
Found the docs for 402, they exist in the PHP and Python tutorials, but are inconsistent across them. Will fix myself. |
|
|
7ebeb1872014ced9ec27e568fae93a928fcc7312 should conclude the work on the tipping specification. Note that the documentation is spread over the PHP/Python tutorials and the API specification. However, it should be internally consistent. Next steps for tipping involve: 1) Implement (and test) support for tips in the merchant backend. 2) Implement (and test) support for tips in the Wallet 3) Integrate tipping with the demo 4) Update tutorials/documentation to document final status and possibly provide nicer guide. |
|
|
Started with implementation of tipping API. High-level /tip-enable and /tip-authorize are done. Next is implementing and testing the backend DB functions (incl. table creation). After that, /tip-pickup should be done (most complex as we may need to fetch /keys from the exchange). Finally, we need the exchange C API and testcases. |
|
|
The merchant *backend* is now done. The next step is to modify one of our *frontends* to offer tips to visitors (hence assigning to Marcello). What I'd like to see is a simple page "survey.demo.taler.net" which asks me a simple question (like, "what do you prefer, Taler or Visa?") with an HTML form. When I click submit, the Web site reacts with the 402 tip offer (as a reward for participating in the 'survey'). Internally, the frontend will need to authorize a tip at the backend to obtain the tip-id. For the demo's operations, we'll need to modify the bank so we can do a wire transfer to a reserve *manually* (i.e. from a "tip account" via some 'manual transfer' option, I believe that was previously requested by me anyway, not sure if a bug ID exists) and then /tip-enable the reserve (for the latter I guess I ought to still hack up a command-line tool as part of the merchant backend). Once the 402 tip is given to the wallet, we should assign the bug to Florian for the final 'wallet' part. |
|
|
febb6d9@survey.git implements this tips-awarding form. It has been tested to the extent of only the merchant backend being involved. You should find it at https://survey.test.taler.net/. So for the moment this bug goes to Florian. |
|
|
Completely implemented in the wallet (and also working overall) in ee9adea89a5 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-06-29 18:26 | Florian Dold | New Issue | |
| 2017-06-29 19:10 | Florian Dold | Note Added: 0012280 | |
| 2017-06-29 19:20 | Christian Grothoff | Note Added: 0012281 | |
| 2017-06-29 19:20 | Christian Grothoff | Severity | minor => feature |
| 2017-10-12 21:02 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2017-10-12 21:02 | Christian Grothoff | Status | new => assigned |
| 2017-10-12 21:02 | Christian Grothoff | Product Version | => git (master) |
| 2017-10-12 21:02 | Christian Grothoff | Target Version | => 0.5 |
| 2017-10-14 11:07 | Christian Grothoff | Note Added: 0012478 | |
| 2017-10-14 11:07 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2017-10-15 15:02 | Christian Grothoff | Note Added: 0012479 | |
| 2017-10-15 15:02 | Christian Grothoff | Assigned To | Florian Dold => Christian Grothoff |
| 2017-10-15 17:38 | Christian Grothoff | Note Added: 0012480 | |
| 2017-10-22 19:09 | Christian Grothoff | Note Added: 0012502 | |
| 2017-10-24 15:39 | Christian Grothoff | Priority | normal => urgent |
| 2017-11-02 17:30 | Christian Grothoff | Assigned To | Christian Grothoff => Marcello Stanisci |
| 2017-11-02 17:35 | Christian Grothoff | Note Added: 0012536 | |
| 2017-11-02 17:47 | Christian Grothoff | Relationship added | parent of 0005169 |
| 2017-11-21 17:55 | Marcello Stanisci | Note Added: 0012595 | |
| 2017-11-21 17:56 | Marcello Stanisci | Assigned To | Marcello Stanisci => Florian Dold |
| 2017-12-09 15:57 | Florian Dold | Status | assigned => resolved |
| 2017-12-09 15:57 | Florian Dold | Resolution | open => fixed |
| 2017-12-09 15:57 | Florian Dold | Note Added: 0012646 | |
| 2017-12-09 17:33 | Christian Grothoff | Fixed in Version | => 0.5 |
| 2018-04-15 20:34 | Christian Grothoff | Status | resolved => closed |
