Requests

A Request represents a call for payment initiated by the merchant, directed at the end user. It specifies the need for a payment to be made in a particular cryptocurrency on a chosen blockchain. The fulfillment of a Request can either be satisfied or remain outstanding. The merchant has the option to define the payment amount in fiat currency, and Inqud efficiently handles the conversion of this fiat amount into the equivalent cryptocurrency.

A Request is usually formed as part of the Checkout process. For businesses aiming to explore more intricate and sophisticated applications in crypto acquiring, there's the option to generate Requests through the Inqud API.

It's important to note that Requests created via the API cannot be displayed using Inqud's default tools like the hosted page or widget. This necessitates that businesses craft their own user interface to present these Requests to their end users.

If you are about to unlock complex crypto acquiring scenarios:

⚙️API Only

Request Types

Fixed Price Request: This is a request for the end user to pay a predetermined amount of a specific cryptocurrency on a chosen blockchain.

No Price Request: This request type asks the end user to pay an amount of their choosing, in a specified cryptocurrency on a designated blockchain, as long as it falls within Inqud's set minimum and maximum limits. This approach provides end users with the flexibility to decide their payment amount.

Request Statuses:

WAITING_PAYMENT: This status indicates that a request has been created, but the end user has not yet initiated a blockchain transaction, or the Inqud system has not detected such a transaction yet.

PENDING_PAYMENT: This status is assigned when the end user's transaction has been detected and is in the process of being handled by the system.

CONFLICT: This status occurs when a transaction initiated by the end user is detected and processed, but certain problems are identified. These problems may include discrepancies in the payment amount, such as not meeting the expected value, or failures in compliance checks, like Anti-Money Laundering (AML) regulations. To provide more detailed insight into the issue, a substatus called 'Reason' is used. Reason statuses:

• UNDERPAID: This indicates that the user has paid an amount less than what was expected.

• OTHER: This is used for various other issues that might arise with the payment, not covered by the specific substatuses.

EXPIRED: This status is used when the end user's transaction has not been detected and the allotted time for the request has elapsed.

SUCCESS: This status signifies that the end user's transaction has been detected, successfully processed, and all necessary checks have been passed. Additionally, the transaction amount fulfills the requirements of the request.

State machine