Kriya Orders API
The Orders API from Kriya — 7 operation(s) for orders.
Work with this as data
Every API here is available over the APIs.io API and to AI agents over MCP.
MCP server
One button, every client — Claude, Cursor, VS Code and the rest.
https://apis.io/mcp
Tools for apis
7 MCP tools reach this
find_apisBrowse and filter every API in the catalog.get_api_artifactsOne API's artifacts, grouped by type.get_openapiThe primary OpenAPI for this API.find_similar_apisAPIs that look like this one.apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.resolveTurn a domain, URL or GitHub org into the provider it belongs to.find_cohortsEvery scored population of providers in the catalog.
Call it yourself
curl for this page
This API
curl "https://apis.io/api/v1/apis/kriya-orders-api"
All apis
curl "https://apis.io/api/v1/apis?limit=25"Discovery needs no key. Ratings and market analysis are Pro.
Get an API key
Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.
A second provider on the same verified email joins the account you already have.
OpenAPI Specification
openapi: 3.2.0
info:
title: Kriya Payments Orders API
description: "<a name=\"introduction\"></a>\n# Introduction\nWelcome to Kriya Payments API, the platform that allows partners to offer a Buy Now Pay Later (BNPL) payment scheme to their business customers.\n\n>Access to the API is restricted to select partners, and those with access will have received the relevant credentials.\n\nDevelopers can use this documentation to understand how to implement the BNPL scheme.\n\nWant to learn more about Kriya Payments? You can either request a demo [here](https://kriya.co/embeddedfinance) or contact us at <payments@kriya.co>.\n\n## Cross-Origin Resource Sharing\n\nThis API features Cross-Origin Resource Sharing (CORS) implemented in compliance with W3C spec. And that allows cross-domain communication from the browser. Furthermore, all responses have a wildcard same-origin, making them wholly public and accessible to everyone, including any code on any site.\n\n## Authorization\n\nOnce approved to use the API, you will have access to your API keys that you must send using the header `X-Kriya-ApiKey` with every request.\n\nRequests and responses must use [JSON](https://www.json.org/).\n\nAll API requests must be sent over HTTPS.\n\n<a name=\"rate-limiting\"></a>\n## Rate Limiting\n\nThe API limits the number of requests that can be made. This approach ensures we can continue to have a reliable API for partners to consume.\n\nRequests are measured over a specified period per API key. The current limitations are that no more than 2000 requests can be made to the API every 5 minutes across the majority of the endpoints (except on the Search endpoint that has a limitation of 5 requests per second). If the limit is breached, the API will begin to respond with `429 Too Many Requests` until the time interval has been refreshed.\n\nIf limits are consistently breached on the API, we may temporarily disable your access to the API and inform you of this.\n\n## Response Status Codes\n\nAPI requests made to Kriya Payments endpoints may return several different HTTP status codes.\n\n| Status Code | Description |\n|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 200 OK | The request was received and successfully processed by Kriya Payments. |\n| 201 Created | The request was received and successfully processed, and a new resource was created. |\n| 400 Bad Request | The request body could not be understood by the server or contains semantic errors. The response body provides details of the specific reason for the error. |\n| 401 Unauthorized | The `X-Kriya-ApiKey` header was not present or is invalid. |\n| 404 Not Found | The requested resource could not be found. |\n| 429 Too Many Requests | The application has exceeded the rate limit. See [Rate Limiting](#rate-limiting). |\n| 500 Internal Server Error | An unexpected internal error has occurred. Please get in touch with us at <apisupport@kriya.co> so that we can investigate further. |\n| 503 Service Unavailable | The server is currently unavailable and cannot accept requests. We will inform Merchants of any planned downtime or outages. If you have not received any communication and you have received this response code, please get in touch with us at <apisupport@kriya.co>. |\n\n<a name=\"definitions\"></a>\n# Definitions\n\n**Merchant**: The Merchant is the partner that will integrate with the Kriya Payments API. This is typically an online platform that provides goods or services to Buyers, either directly or via Suppliers.\n\n**Buyer**: A Buyer is a business that is purchasing goods or services from the Merchant. A Buyer must be registered on Kriya Payments API and be given an approved spending limit before being able to transact with us.\n\n**Supplier**: A Supplier is a business that provides goods or services to be sold via the Merchant. The Supplier must be registered and approved on Kriya Payments API before the Merchant sells goods or services on their behalf. A Supplier may also be a Buyer on either the same or other Merchants.\n\n**Order**: An order is an agreement between the Buyer, Supplier, and the Merchant of buying goods and services. The value of the order may be the sum of one or many goods or services. An individual order can be purchased via the BNPL options provided to Buyers.\n\n**Buyer Spending Limit**: The spending limit is the total amount that Kriya Payments can offer a Buyer to transact with. Kriya Payments continually monitors the spending limits assigned to Buyers and may increase or decrease them.\n\n**Buyer Available Spending Limit**: The available spending limit is the amount that the Buyer can use to transact using Kriya Payments. Whenever an order progresses beyond the `Draft` status, the total amount of the order is deducted from the available spending limit. All orders made must fall within the available spending limit for the Buyer.\n\n**Merchant Spending Limit**: This is the total amount that Kriya Payments can offer to fund orders placed by any buyers with the merchant. Kriya Payments monitors the spending limits assigned to Buyers and may increase or decrease them.\n\n**Merchant Available Spending Limit**: This is the amount the merchant can use to receive advance funding from Kriya Payments for buyers’ orders. The advance rate value of the order is deducted from the available funding limit when an order progresses beyond the `Draft` status.\n\n**Kriya Payments Fee**: Orders created may be paid for from several payment methods, e.g. \"Pay in 30 days\". Each payment method may include a fee that is payable by the Buyer that is based on a percentage of the order amount. When the Buyers available spending limit is reduced, it is exclusive of fees. For example, a Buyer may want to pay for a £1,000 order using a payment method that has a 1.00% fee. The total amount payable by the Buyer would be £1,010, and their available spending limit is reduced by £1,000.\n\n**Payment Method**: A payment method is a specific term under which an order is to be paid. For example, \"Pay in 30 days\" or \"Pay in 3 instalments\". Each Merchant and Buyer can have different methods provided to them at the checkout stage. Fees associated with payment methods can be set globally or overridden for specific Buyers.\n\n**Additional Onboarding Checks**: Additional AML checks requested by merchant. You can find more information [here](https://docs.kriya.co/onboarding#section/Definitions).\n\n**2FA**: Two-factor authentication (2FA) is a security process in which users provide two different authentication factors to verify themselves. Kriya will verify the user's phone number. \n\n**Buyer user admin**: An employee of a buyer who can manage buyer users and place orders on behalf of the buyer company. \n\n**Buyer user**: An employee of the buyer who can place orders on behalf of the buyer company. \n\n# Additional Security Levels Provided by Kriya\nDefault checks that are required by Kriya - Risk checks for Sole Traders and Limited Companies. They are always presented and can not be elevated. \n\n- Additional layers of security may be added by Merchant request. They include:\n- Additional onboarding checks that may include any combinations of the following: \n - Selfie Check\n - Identity Verification and Proof of Address\n - Sanction Screening\n \n For Limited Company the checks should be completed by registered director. Sole Trader can undergo the process by themselves. Until their successful completion the order placement (except draft ones) for this Limited Company will be blocked. There is a limitations for Limited Company checks: right now Kriya can perform them only for UK based companies.\n- 2FA \n \n 2FA involves two types of roles: `buyer user admin` and `buyer user` (please check [definitions](#definitions) for more details). Kriya considers users who passed additional onboarding check as user admin. They can approve orders and reach out to support. Kriya considers users who initiated successful onboarding process and successfully submitted an order as a 'regular user'. They can create new orders without approval from admins. 2FA pause submission or the modification of submitted orders until approval is received. \n \n<a name=\"integration-scenarios\"></a>\n# Integration Scenarios\n\nThe Kriya Payments API provides a variety of methods of integration for partners. This includes direct API integration and a Kriya Payments-hosted Payments Journey web application.\n\nThe following table outlines the differences in scenarios:\n\n| Property | Direct API | Payments Journey |\n|--------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Effort | The estimated effort of between 1-4 weeks to implement. The developer effort is more significant as it involves a bespoke integration built by the Merchant. | The estimated effort of around one week to implement. Lower development effort as the majority of the integration is handled by the Kriya Payments Payments Journey with only minimal API integration required by the Merchant. |\n| Limitations | Currently Direct Api doesn't support sole trader creation. | |\n| Checkout data collection | Additional fields, if not currently exposed, may be required to create a Kriya Payments order that the Merchant must embed in their checkouts. | Kriya Payments collects Company and User details on your behalf. Returning Buyers also have their previous data pre-populated to increase the speed of the checkout process. |\n| Branding | The integration will be built by the Merchant, and any branding can be fully controlled. | Co-branding is limited to displaying the Merchant logo, but further enhancements are on the roadmap. |\n| User experience | The Merchant must define its UX and UI for its Buyers that align with the [API flows](#direct-api-integration). Users stay within the domain of the Merchant website. | User experience is pre-defined by Kriya Payments and optimised based on regularly reviewed metrics collected from customers that use the Payment Journey. Users must be redirected to an external site to continue their checkout journey. |\n| API Updates | Changes to Kriya Payments API, including any new capabilities, will have to be developed by the Merchant. | Payments Journey will constantly be kept up to date with the latest API capabilities to ensure the customer has a high-quality experience. |\n\n<a name=\"direct-api-integration\"></a>\n## Direct API Integration\n\nDirect API integration is the preferred choice for partners that want to have significant control over the customer journey and embed the capabilities of the API directly into their solutions. However, not all scenarios are covered end-to-end by direct API, some of them require a mixed approach with direct API and [Onboarding Journey web application](https://docs.kriya.co/onboarding#section/Onboarding-Journey-Integration). \n\n### Direct API flow\n\nThe following flow demonstrates the only end-to-end scenario that is covering a sequence for a new Limited Company Buyer transacting using the API when Merchant does not require additional onboarding checks:\n\n1. **Buyer** has been searched on the Kriya Payments API `Search` endpoint and chosen from the list.\n2. **Buyer** has been onboarded by the Merchant.\n3. **Merchant** requests to the Kriya Payments API `CreateBuyer` endpoint to register them on the API to identify if they can use Kriya Payments.\n4. **Kriya Payments API** begins the risk decision process to determine if a limit can be provided to the Buyer.\n5. **Kriya Payments API** responds with a `201 Created` status code to confirm the Buyer has been created.\n>Note: Merchants may create `Draft` orders whilst awaiting a risk decision. However, no orders can be `Submitted` until the Buyer has been `Approved`. See [Webhooks](#webhooks) for more details on how to get notified of this.\n6. **Merchant** uses [webhooks](#webhooks) or the `GetBuyer` endpoint to determine whether the Buyer has been `Approved` and Kriya payment methods are available to them.\n7. **Merchant** may call the Kriya Payments API `GetBuyerPricingScheme` endpoint to understand which payment methods are available to the Buyer, along with any associated fees they may incur.\n8. **Kriya Payments API** responds with a `200 OK` response and provides the pricing scheme available to the Buyer.\n9. **Buyer** uses the Merchant to purchase services or goods and chooses to pay with Kriya Payments, presuming the Merchant has exposed the ability to check out using Kriya Payments.\n10. **Merchant** calls the Kriya Payments API `CreateOrder` endpoint, which will create a new order in the default `Draft` status.\n> A `Draft` order is non-committal and can be cancelled at any time. It does not impact the available spending limit of the Buyer.\n11. **Kriya Payments API** responds with a `201 Created` to confirm the order has been created and also returns details about the Buyer's possible payment methods and limit.\n12. **Buyer** confirms they want to proceed and place the order on the Merchant.\n13. **Merchant** calls the Kriya Payments API `TransitionOrder` endpoint and moves it from the `Draft` status to `Submitted`. If the Merchant requires additional onboarding checks before any company order placement, the response will depend on whether any of the company's directors have passed them. For more details on additional onboarding checks, please refer to the [Kriya Onboarding](https://docs.kriya.co/onboarding) section.\n> By transitioning the order to a `Submitted` status, the Buyers available spending limit is reduced based on the total amount of the order.\n14. **Kriya Payments API** responds with a `200 OK` response.\n15. **Merchant** delivers the goods to the Buyer, and an invoice has been generated.\n16. **Merchant** requests to the Kriya Payments API `TransitionOrder` endpoint and moves it from `Submitted` status to `ReadyToAdvance`.\n> This is the trigger from the Merchant to inform Kriya Payments to advance funds to the Merchant and Supplier if applicable. No further changes can be made to the order at this point.\n17. **Kriya Payments API** responds with a `200 OK` response.\n\n\n\n<details>\n<summary> <b>Company Search</b> </summary>\nKriyaCompanyIdentifier is mandatory when you want to onboard buyers/suppliers to get an instant decisioning for them.</br>\nTo get it Company search must be used.\n\nPlease feel free to use the following code to test search functionality: \n```\n const url = 'https://api.kriya.dev/payments/companies/search'; \n const headers = {\n 'Content-Type': 'application/json',\n 'X-Kriya-ApiKey': '<please replace with your api key>'\n }\n const data = {\n address: {\n country: 'GB'\n },\n name: 'Apple'\n }\n \n axios.post(url, data, {headers: headers})\n .then(function (response) {\n console.log(response.data);\n })\n .catch(function (error) {\n console.error('Request failed:', error);\n });\n \n```\nThere are many ways to search for companies depending on the company data at hand. However, we strongly recommend prioritising searches using NationalIds, as they have a higher probability of providing exact matches, rather than lists of probable companies.\nA NationalId is a unique identifier of a company provided by its country of registration: for example, for the UK it is the Company Registration Number (CRN), while for Italy can be either \"Chamber of Commerce Number\", \"Value Added Tax Number\" or \"Fiscal Code\".\nOther searches should only be relied on in case of search failure (0 matches) using NationalIds.\n\nThe following combinations tend to favour exact matches, in order of precision:\n* CountryCode + NationalId (typically returns a single match)\n* URL or email (depends on the availability of the info in the database)\n\nThe other type of search is via Name + Address (partial match), which usually retrieves a list of companies.\n\nThe United States and Canada do not have a nationwide NationalId database to uniquely identify companies. For this reason, the only way to successfully search for a company is using Name + Address or URL/email search.\nNOTE: The resulting list of companies contains only the following:\n* Stand-alone companies.\n* Headquarters.\n* Subsidiaries.\nIn other words, if the search is for a company with branches, you won’t find any branches but only headquarters.\n\n\nExample of a response payload\n```json\n{\n \"kriyaCompanyIdentifier\": \"31c421ca-ec6e-44fa-a78d-9fe6e841c580\",\n \"name\": \"string\",\n \"nationalId\": \"string\",\n \"address\": {\n \"addressLine1\": \"string\",\n \"addressLine2\": \"string\",\n \"city\": \"string\",\n \"region\": \"string\",\n \"postCode\": \"string\",\n \"country\": \"string\"\n },\n \"website\": \"string\",\n \"email\": \"string\"\n}\n```\n</details>\n\n### Scenarios that require mixed approach (direct API + Onboarding Journey web application) \n- **Buyer is a Sole Trader who has not been onboarded to Kriya yet and who wants to transact**\n\n Above sequence will be changed in the following way: \n - Step [1-5] will be replaced by Sole Trader Onboarding Journey. More information about this can be found [here](https://docs.kriya.co/onboarding#section/Onboarding-Journey-Integration/Sole-Trader-Onboarding).\n - Step [6]: Merchant still can use [webhooks](#webhooks) or `GetBuyer` to determine whether the Buyer has been `Approved`. \n\n\n- **Merchant requires additional onboarding checks and Buyer does not have any director who has been undergone them**\n \n Above sequence \n - should be interrupted after Step [12] \n - should have additional step for the director to pass additional onboarding checks. More detailed information can be found [here](https://docs.kriya.co/onboarding).\n - should be resumed from Step[13] after Merchant by means of [webhooks](#webhooks) endpoint receive information about successful Onboarding checks completion.\n\n\n- **Merchant requires 2FA approval for order placement and order is being placed by a user who has not submitted any order or initiated additional onboarding checks**\n \n Above sequence will be changed in the following way:\n - Step[13] return a SessionStatusUrl that can be used for tracking of 2FA progress and clarification message that includes information about approvers.\n - Approval process that was initiated in Step [13] has the following steps:\n - **Kriya Payments API** initiates 2FA Session. Part of this process is gathering information about buyer user admins (see [definitions](#definitions) for more details) and sending out SMS with the link to Payment Journey page where they can approve the operation. Session expiration time is 5 minutes. If decision has not been received by Kriya within this timeframe operation considered as abandoned and request should be resent again.\n - **Buyer User Admin** open a received in SMS link to Payment Journey and approve or reject the operation\n - **Payment Journey** passes the decision to Kriya Payments API\n - **Kriya Payments API** completes the session and resume or abandon the operation based on the received decision.\n - **Merchant** can use [webhooks](#webhooks) to track the positive outcome of the 2FA flow or use `GetOrderMfaSession` endpoint to track all possible outcomes\n \n <img style=\"margin: 20px 50px\" src=\"https://cdn.kriya.co/images/2FA-Flow.png\" alt=\"2FA Flow\"/>\n \n - the sequence resumes from Step [15]\n\n<a name=\"payments-journey-integration\"></a>\n## Payments Journey Integration\n\nThe Payments Journey-driven integration utilises a Kriya Payments-hosted web application that handles the checkout journey for customers. Additionally, Payment Journey seamlessly handle over control to Onboarding Journey to cover scenarios related to buyer's onboarding and company checks. This is the preferred approach for partners that are looking for a lower-effort solution that unlocks the full functionality provided by Kriya.\n\n### Payments Journey Demonstration\n\nThe following file shows a walk-through of an end-to-end journey from the customer's perspective once they have been redirected to the Kriya Payments hosted Payments Journey.\n\n\n\n\n### Payments Journey flow\n\nThe following flow shows a typical scenario for the Payments Journey. A Limited Company Buyer has chosen to pay using Kriya Payments on the Merchant that does not require any additional checks, and they will complete their checkout process via the Payments Journey before being redirected back to the Merchant.\n\n1. **Buyer**, existing or new, has been onboarded by the Merchant and has been offered Kriya Payments.\n2. **Merchant** calls the Kriya Payments API `CreateOrder` endpoint, which will create a new order in the default `Draft` status.\n> To initiate a payment journey additional fields are required. See, `Initiating a payment journey` below.\n3. **Kriya Payments API** responds with a `201 Created` status code to confirm it has been created and also returns a redirect URL, which is valid for 14 days.\n> The redirect URL is used to redirect the customer to the Kriya Payments-hosted Payments Journey.\n4. **Merchant** redirects the customer to the returned URL.\n5. **Buyer** lands on the Payments Journey page, which includes filling out Company and User details if they were not initially provided in step 2.\n6. **Buyer** selects their preferred payment method and finally completes their payment journey.\n7. **Payments Journey** redirects the Buyer back to the Merchant.\n8. **Buyer** places the order on the Merchant.\n> If your checkout process does not require the Buyer to confirm the placement of the order, you can use our `AutoTransitionOnCompletion` field, which automatically performs step 9 for you. See below for further details.\n9. **Merchant** calls the Kriya Payments API `TransitionOrder` endpoint and moves it from `Draft` to `Submitted`. If the Merchant requires any additional onboarding checks before any company order placement, the response will depend on whether any of the company's directors have passed them. For more details on additional onboarding checks, please refer to the [Kriya Onboarding](https://docs.kriya.co/onboarding) section.\n> By transitioning the order to the `Submitted` status, the Buyer's available spending limit is reduced based on the total amount of the order.\n10. **Kriya Payments API** responds with a `200 OK` response to confirm that the order has been submitted.\n> At this point, the same steps from 11 onwards in the `API flow` are now followed.\n\n\n\n \nAll scenarios where Payment Journey handle over control to Onboarding Journey can be found [here](https://docs.kriya.co/onboarding#section/Onboarding-Journey-Integration/Payment-Journey-and-Onboarding-Journey-integration). They are related for the cases when buyer's onboarding or company checks are required.\n\n### Payments Journey flow with 2FA\nThe following flow shows a typical scenario when Merchant is requesting 2FA and a Limited Company Buyer has chosen to pay using Kriya Payments.\n\n\n\n**AutoTransitionOnCompletion**\n\nThis property defines the status that the order will transition to after the payment journey is completed but before redirecting them back to the Merchant. By default, any payment journey completion will leave an order in its `Draft` status. However, this property allows you to transition an order to `Submitted` or `ReadyToAdvance` instead automatically.\n\n### Initiating a Payment Journey\n\nTwo properties must be specified to ensure you receive a redirect URL to the Payments Journey:\n\n**PaymentAcceptedRedirectUrl**\n\nThis refers to the URL that we will redirect the Buyer to once they have completed the Payments Journey. Upon redirection, you will now have an order that has been created, still in the `Draft` status, unless the `AutoTransitionOnCompletion` property has been set.\n\n**PaymentDeclinedRedirectUrl**\n\nThis refers to the URL that we will redirect the Buyer to if, at any point in the journey, they either do not wish to proceed or cannot proceed. Upon redirection, you will still have an order that has been created, still in the `Draft` status, which can be set to `Cancelled` if applicable. You will be able to retrieve the details about why the Payments Journey has been declined by retrieving the order details via the Kriya Payments API `GetOrder` endpoint, which will include a `PaymentJourney.Status` property that will be either:\n\n- **UserInitiated** - The user decided to return to the Merchant and no longer proceed with the order at this time. e.g. They may wish to add additional items to their basket or choose an alternative payment method. The Merchant can amend the order amount (`PUT` on the orders endpoint) and redirect the Buyer back to the payments journey, if applicable.\n- **Ineligible** - Kriya Payments were unable to transact with the Buyer as they have not been or are no longer approved. The Merchant is expected to provide the Buyer with an alternative payment method.\n- **InsufficientFunds** - Kriya Payments were unable to transact with the Buyer as their available spending limit is less than the amount of the current order. The Merchant is expected to either provide the Buyer with an alternative payment method or provide partial payment so that Kriya can still transact with the funds available on the Buyer's available spending limit.\n- **OnboardingChecksAreRequired** - Kriya Payments couldn't process the transaction with the Buyer due to the failure of the Merchant's requirement for one of its directors to complete additional onboarding checks. For more details on additional onboarding checks, please refer to the [Kriya Onboarding](https://docs.kriya.co/onboarding) section.\n- **OnboardingChecksAreFailed** - Kriya Payments couldn't process the transaction with the Buyer due to the failure of the Merchant's requirement for one of its directors to successfully complete additional onboarding checks. For more details on additional onboarding checks, please refer to the [Kriya Onboarding](https://docs.kriya.co/onboarding) section.\n- **InsufficientFundsOnboardingChecksAreRequired** - Kriya Payments were unable to transact with the Buyer as their available spending limit is less than the amount of the current order and due to the failure of the Merchant's requirement for one of its directors to complete additional onboarding checks. For more details on additional onboarding checks, please refer to the [Kriya Onboarding](https://docs.kriya.co/onboarding) section.\n\n**Configuration**\n\nThe configuration of this feature is completed as part of the onboarding process as a Merchant to provide the initial setting. If this needs to be changed, please contact your Kriya account manager.\n\n## BigCommerce\n\nKriya Payments is now available for BigCommerce merchant stores. In addition, it can be downloaded for free directly from the [BigCommerce App Marketplace](https://www.bigcommerce.co.uk/apps/kriya-payments/).\n\n### Configuring the app\n\n1. Follow the link to the [BigCommerce App Marketplace](https://www.bigcommerce.co.uk/apps/kriya-payments/) and select `GET THIS APP`.\n2. Sign in to your BigCommerce store when prompted if you still need to do so.\n3. Select `Install`.\n4. Review the permissions that the app requires, check the compliance box and select `Confirm`.\n\n\n\nAt this point, the app has now been installed. To configure the app for your store, you need to link your BigCommerce store to your Kriya account:\n\n1. Enter your `Merchant Id` and `Secret Key` that you should have received from Kriya.\n2. Select `Continue`.\n\n\n\nOnce the app has been linked to Kriya, it is ready to be enabled to appear on the stores checkout page.\nThe app allows for it to be used for a subset of users against our `Test` environment before deploying it to your live store for all customers. \nThe app is in the `Test` mode when installed by default. To show the `Kriya Payments` option to specific users whilst in `Test` mode, you need to enter the e-mail address of a registered user into the appropriate field and select `ADD USER`.\nOnly these users will be able to see and use the app.\n<br/>\n\nOnce you're ready to show the `Kriya Payments` payment option to all of your customers on the live store, you need to switch the toggle from `Test` to `Production`.\n\n ---
# Full source: https://raw.githubusercontent.com/api-evangelist/kriya/refs/heads/main/openapi/kriya-orders-api-openapi.yml