Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regarding users KYC level #31

Closed
leihog opened this issue Oct 4, 2016 · 7 comments
Closed

Regarding users KYC level #31

leihog opened this issue Oct 4, 2016 · 7 comments

Comments

@leihog
Copy link

leihog commented Oct 4, 2016

It seems to me that there isn’t an easy way for us to tell that a user needs to perform an action in order to fulfill the KYC requirements. For example if a user with KYC level light spends more than €2500 which requires them to upload additional information.

So in order to know that a user needs to perform a KYC we have to wait for the API to raise an exception. So far so good. We catch this exception and flag our user as requiring a new KYC level.
Here is where it becomes messy.

In order to know that the users new KYC has been approved we need to poll the API
(possibly as the result of a KYC_SUCCEEDED event) to see if the users KYC level has changed.
This means that we need to store the current KYC level locally.

It would be much easier if the user entity had a flag stating whether or not the user was required to take action. Such as KYCValidationRequired = true, in addition to the current KYCLevel.

A couple of new hooks would also be very useful, KYC_LEVEL_CHANGED & KYC_VALIDATION_REQUIRED. Both of which would return a user id.

Thoughts?

@hobailey
Copy link
Contributor

Hi @leihog, thanks very much for the feedback and ideas. A couple of things:

  • We're aware the KYC management isn't optimal and we're working on several new endpoints to make the process more transparent - these will include seeing the amount of emoney in and out a user has done (so you know how far from the limits they are, or even if the user has gone over them) and also an endpoint for use when a transaction is blocked for KYC reasons that allows you to see all the users that need to be validated for this transaction to be possible.
  • In terms of being notified when the KYC level changes, could you not use the KYC_SUCCEEDED hook and check the level each time? As you say, you'll need to have stored the previous level, but even if there was a "KYC_LEVEL_CHANGED" type hook, you'd still have needed to know the previous level, right?

@hobailey
Copy link
Contributor

OK, fair enough. Well the new endpoints should help and they'll be available in the next couple of months (keep an eye on the blog/newsletter), and we've noted the point about the KYC status changes but I don't have a date at this time I'm afraid.
I'll close this ticket for now if that's OK.

@leihog
Copy link
Author

leihog commented Oct 10, 2016

We currently do listen for KYC_SUCCEEDED and fetch the document, then fetch the user to find out if the level changed. It works but it requires two API calls.
The suggested event "KYC_LEVEL_CHANGED" would allow us to do the same thing with just one API call and it would be triggered only when the level had changed as opposed to everytime a document has been approved. There can be multiple documents so this will be triggered more often and to be honest knowing that a document got approved isn't very valuable to us or our customers. The only thing we are interested in is that any restrictions on the user has been lifted.

The idea behind KYC_VALIDATION_REQUIRED is similar in that we wouldn't have to listen for failed payouts and payins and instead just listen for this event to know that a user needs to do their KYC.

Anyway, we can make do with what we have.
I'm happy to hear that you are working on improvements, keep up the good work! :)

@hobailey
Copy link
Contributor

OK, thanks. As for "KYC_VALIDATION_REQUIRED", you'd still need to listen for failed transactions to know which ones to rerun once the user has been KYC validated, right?

@leihog
Copy link
Author

leihog commented Oct 10, 2016

Well, we probably would but not necessarily. We could also just leave it up to the user to make a new attempt after they have completed their KYC. Considering that it might takes several days between the failed attempt and the KYC documents being uploaded and validated, the circumstances leading to the payout may have changed. The user may for instance have more money to withdraw now.

In either case the separation of concern is still useful to us as it allows us to build leaner code and the other upside is that it lets us make less requests to your API. The way I see it, It's a win win situation.

@hobailey
Copy link
Contributor

Absolutely - I totally agree, I just wanted to check this point :-)

@Aasif001
Copy link

Aasif001 commented Nov 5, 2018

How can I check the STATUS of KYC document.
I don't find any sample code for KYC HOOKS and how it exactly works

`
public function createKYCHook()
{
$mangoPayApi=$this->initMangoPay();
try {
$Hook = new \MangoPay\Hook();
$Hook->Tag = "KYC UPDATE HOOK";
$Hook->EventType = "KYC_SUCCEEDED";
$Hook->Url = $this->get_helper_url('payment_main_domain')."/updateKYC/";
$Result = $mangoPayApi->Hooks->Create($Hook);
} catch(MangoPay\Libraries\ResponseException $e) {
// handle/log the response exception with code $e->GetCode(), message $e->GetMessage() and error(s) $e->GetErrorDetails()
} catch(MangoPay\Libraries\Exception $e) {
// handle/log the exception $e->GetMessage()
}
}

public function updateKYC(Request $request)
{
$kycUserLists=DB::table('tbl_mangopay_kyc')->where('status','VALIDATION_ASKED')->get();
$mangoPayApi=$this->initMangoPay();

foreach($kycUserLists as $kycUserLists)
{
$KYCDocumentId = $kycUserLists->kyc_id;
$KycDocument = json_encode($mangoPayApi->Users->GetKycDocument($kycUserLists->mangopay_user_id,$KYCDocumentId));
DB::table('tbl_dummy')->insert(['tag'=>$KycDocument]);
$KycDocument=json_decode($KycDocument,true);
if($KycDocument->status=="VALIDATED")
{
DB::table('tbl_mangopay_kyc')->where('kyc_id',$KYCDocumentId)->update(['status'=>'VALIDATED']);
}
}
}
`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants