KYC Verification Flow (General Overview)

• Create or receive a verification (depending on the use case).
• Retrieve required physical documents and/ or fields for that verification.
• Upload files and/or provide field values until all items are complete; system advances to compliance review.
• Receive webhook notifications for status changes.
• Handle resubmissions if requested.
• Verification ends in Approved/Rejected or Expired, as it may expire.

Specific use case flows

Payouts On Hold (POH) verifications

This verification type is created by dLocal when a payout is placed on hold due to fraud compliance concerns. Additional information is required from the merchant to release the funds.

• Dlocal sets payoutON_HOLD_BY_COMPLIANCE.
• Dlocal creates a KYC verification linked to the specific payout.
• The Merchant receives a notification of a KYC verification.
• The Merchant retrieves the list of required documentation for verification, which can be either physical or/fields.
• The Merchant sends the list of required documents.
• Verification transitions to compliance review.
• The Merchant handles resubmissions if requested.
• Verification ends in:
  • APPROVED: payouts related to the verification are released.
  • REJECTED: payouts related to the verification are canceled.
  • EXPIRED: payouts related to the verification are canceled.

API Endpoints

Payins On Hold verifications

This verification type is created by dLocal when one or more payins are placed on hold due to fraud and/or compliance concerns. Additional information is required from the merchant to release the funds.

• dLocal sets the payin(s) to an internal UNDER INVESTIGATION status.
• dLocal creates a PAYINS_ON_HOLD KYC verification linked to the specific payin or group of payins from the same payer.
• The Merchant receives a notification of a KYC verification.
• The Merchant retrieves the list of required documentation for verification, which can be either physical or/fields.
• The Merchant sends the list of required documents.
• Verification transitions to compliance review.
• The Merchant handles resubmissions if requested.
• Verification ends in:
  • APPROVED: payins related to the verification are released.
  • REJECTED: payins related to the verification are refunded.
  • EXPIRED: payins related to the verification are refunded.

API Endpoints

Remittances verifications

This verification type is used for creating Remitter and Beneficiary verifications required for remittance payments.

• The Merchant creates the verification(s) for REMITTER and/or BENEFICIARY, optionally attaching initial documents in the same multipart request if required.
• The Merchant retrieves the required physical documents and/or fields for each verification, if not sent in the creation of the verification.
• Verification transitions to compliance review; notifications are sent to the configurednotification_url.
  The Merchant handles resubmissions if requested.
• Verification ends in:
  • APPROVED: Remitter or Beneficiary ID can be used for payins or payout transactions.
  • REJECTED: The Remitter or Beneficiary verification is rejected.
  • EXPIRED: The Remitter or Beneficiary verification has expired.

API Endpoints

Standalone verifications

• The Merchant requests a standalone KYC verification for an end user via the API.
• dLocal creates a standalone KYC verification.
• The Merchant receives a notification of a KYC verification, along with a list of required documents, which can be either physical documents or fields.
• The Merchant retrieves the list of required documentation for the verification and submits the requested information via the API.
• Verification transitions to compliance review.
• Verification ends in:
  • APPROVED: the result can be used by the Merchant as input to their own flows (for example, to approve or enable features for that end user).
  • REJECTED: The standalone verification is rejected.

📘

Contact your Technical Account Manager to set up your notification URL.