View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009218 | Taler | mechant backend | public | 2024-09-23 20:14 | 2024-12-13 19:15 |
| Reporter | Florian Dold | Assigned To | Florian Dold | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.14 | Fixed in Version | 0.14 | ||
| Summary | 0009218: merchant's /private/kyc endpoint does not update KYC status after AMLO decision | ||||
| Description | The merchant claims outdated limits. When /private/kyc?lpt=3 is requested in a loop, the reported limits remain "limits": [ { "operation_type": "DEPOSIT", "timeframe": { "d_us": 86400000000 }, "threshold": "TESTKUDOS:0", "soft_limit": true } ], despite a manual AMLO decision to lift all limits. I'm *pretty* sure I'm making the AMLO decision with the right h_payto, but the merchant API currently doesn't report the h_payto for the KYC, so I'm simply computing the payto hash of the payto_uri myself. | ||||
| Steps To Reproduce | $ taler-harness run-integrationtests kyc-merchant-deposit | ||||
| Tags | No tags attached. | ||||
| related to | 0009244 | closed | Florian Dold | merchant should refuse order creation when it would trigger a DEPOSIT limit |
|
|
This one is tricky. We're not under AML investigation, we're not under KYC required, we're (at a high level) in a seemingly "normal" operational state (modulo the deposit limit being 0, but that level of detail in the rules is not something we can currently long-poll for or that taler-merchant-kyccheck would care about). So as a result, taler-merchant-kyccheck basically goes into deep hibernation as far as this account+exchange is concerned. Consequently, we don't learn about the rule change :-(. |
|
|
4dc7dc50..58738267 modifies the order creation logic to trigger a KYC check if an order creation failed due to KYC limits. Note that the order creation will still fail (the KYC check is async in another process), we only kick the taler-merchant-kyccheck process to do an immediate check for change of rules. So this is a partial work-around, as it makes sure we (1) can trigger an immediate check, (2) do not keep failing even if the KYC limit was lifted. |
|
|
58738267..c67c2b1d modifies taler-exchange-kyccheck to check at least once per week, even if we have no inherent reason to check. This will ensure that our KYC status is eventually updated even if we do not run into order creation issues (like when we have multiple exchanges and once is good and sufficient for orders (so the above case does not apply), and then a 2nd one *becomes* good, we need to update the 2nd one's status eventually so that we start accepting money from both. |
|
|
Acceptable solution? |
|
|
Yes, but the test still doesn't work properly because of 0009244 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-09-23 20:14 | Florian Dold | New Issue | |
| 2024-09-23 20:14 | Florian Dold | Status | new => assigned |
| 2024-09-23 20:14 | Florian Dold | Assigned To | => Christian Grothoff |
| 2024-09-29 15:30 | Christian Grothoff | Note Added: 0023397 | |
| 2024-09-29 15:46 | Christian Grothoff | Note Added: 0023398 | |
| 2024-09-29 15:50 | Christian Grothoff | Note Added: 0023399 | |
| 2024-09-29 15:50 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-09-29 15:50 | Christian Grothoff | Status | assigned => feedback |
| 2024-09-29 15:50 | Christian Grothoff | Note Added: 0023400 | |
| 2024-10-02 19:31 | Florian Dold | Note Added: 0023427 | |
| 2024-10-02 19:31 | Florian Dold | Relationship added | related to 0009244 |
| 2024-10-07 16:29 | Florian Dold | Status | feedback => resolved |
| 2024-10-07 16:29 | Florian Dold | Resolution | open => fixed |
| 2024-10-07 16:35 | Christian Grothoff | Fixed in Version | => 0.14 |
| 2024-12-13 19:15 | Christian Grothoff | Status | resolved => closed |
