View Issue Details

IDProjectCategoryView StatusLast Update
0009218Talermechant backendpublic2024-10-02 19:31
ReporterFlorian Dold Assigned ToFlorian Dold  
PrioritynormalSeveritymajorReproducibilityalways
Status feedbackResolutionopen 
Target Version0.14 
Summary0009218: merchant's /private/kyc endpoint does not update KYC status after AMLO decision
DescriptionThe 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
TagsNo tags attached.

Relationships

related to 0009244 assignedChristian Grothoff merchant should refuse order creation when it would trigger a DEPOSIT limit 

Activities

Christian Grothoff

2024-09-29 15:30

manager   ~0023397

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 :-(.

Christian Grothoff

2024-09-29 15:46

manager   ~0023398

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.

Christian Grothoff

2024-09-29 15:50

manager   ~0023399

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.

Christian Grothoff

2024-09-29 15:50

manager   ~0023400

Acceptable solution?

Florian Dold

2024-10-02 19:31

manager   ~0023427

Yes, but the test still doesn't work properly because of 0009244

Issue History

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