Skip to main content

Create a Payin Request

POST 
/v2/payins

To be able to successfully create a payin request you would need the following APIs in consideration:

  • Step 1: Call the Get payin methods to retrieve the list of supported methods.
  • Step 2: Call the Get payin required fields to get specific required fields for each method.
  • Step 3: Create the payment using the method and required fields from the previous step.
  • Step 4: On sandbox environment, you can call the Simulate payin to simulate the payment.

Note:

If the payin_method_name is either jp_bank_jpy or au_payid_npp_aud, a pay_code will be sent to the webhook after a certain period with the following fields:

  • For jp_bank_jpy:
    • bank_name: The recipient's bank name.
    • transfer_id: The transfer identifier on the provider side.
    • branch_code: The code of the recipient's bank branch.
    • branch_name: The name of the recipient's bank branch.
    • account_number: The recipient's account number.
    • account_name: The recipient's account name.
    • expired_timestamp: The payment expiration time.
    • account_type: The recipient's account type.
    • transfer_name: The name associated with the transfer.
  • For au_payid_npp_aud:
    • payment_url: The payment url to complete the payment.

If you use one of the following payin methods, please check the list of supported providers before proceeding:

❗ Important:
For Step 3, if you choose mobile_money as the payin method, as the PayIn method, refer to the instructions in the Mobile Money tab.

  • For example: gh_mobile_money_ghs

Request​

Responses​

Created

Callbacks​

POST 
{$request.body#/webhook_notification/endpoint_url}

If the merchant specifies values for the webhook_notification object during the Create payment request invocation, then a notification will be sent to the merchant's system when its status has changed to received or return_received.

The event will use webhook_notification.endpoint_url as endpoint and webhook_notification.authorization_header as Authorization header. We strongly recommend to use a different value for authorization_header on each payment request to increase the level of security.

This call is made by Hello Clever on the best effort basis. Hello Clever will implement retry mechanisms to ensure transient network failures do not affect the ability to call this endpoint. Hello Clever may call this endpoint more than once with the same payload so the merchant must ensure that the endpoint is implemented with idempotent behaviour always returning a 200 OK response even after subsequent calls.

If the target endpoint does not return HTTP 200, Hello Clever will retry the webhook call 3 times with 15 minutes delay per call.

Callbacks Responses​

The merchant's server should return this code