- Meld KYCes the user: You call Meld’s API to get back a KYC link and launch it from your UI; Meld handles the rest. This is the best flow from a user experience standpoint, as Meld will ensure it collects all KYC data required by the downstream onramps.
- You KYC the user: You integrate a KYC provider yourself, run the user through their KYC process, track status, then pass the KYC token or the raw KYC data to Meld. Since this flow is more work for you, and you would need to ensure that you collect all of the KYC data that the onramps require, this flow is only recommended if you’re already KYCing users with a KYC provider.
- Retrieve KYC Data: If you have a use case where you need the KYC data of your existing users, such as to KYC them for a separate product you are offering, you can fetch a KYC token or the raw KYC data of the user from Meld.
Which flow should I use?
Share KYC with providers
Approving a customer does not on its own reach every onramp. Providers that take their KYC as a share from Meld, such as Banxa, receive it only if you name them inkycShareProviders on kyc/initiate. This works the same whichever flow starts the KYC: HOSTED_URL, TOKEN_IMPORT or RAW_DATA_IMPORT.
- Name every provider you will order with whose KYC comes from a share. Meld shares with each one once the customer is approved. A provider left out never receives the customer’s KYC, and its orders are refused with
403 KYC_NOT_COMPLETED. Eligibility reports this asPROVIDER_KYC_SHAREfor the provider. - To add a provider for a customer who is already approved, call
PATCH /accounts/customers/{customerId}/kyc/initiatewith the same body, naming the new provider inkycShareProviders.serviceProviderandmodeare still required. Meld shares straight away, without sending the customer through KYC again. - A
POSTnaming a provider the customer was already shared with returns409. Use thePATCHinstead.