Integrating with Dojo

Recently, we’ve implemented the Dojo integration for our client who already has a custom CRM we are maintaining at the moment.

Implementing integration with Dojo had its challenges, so in this article outlined are the steps to successful integration with Dojo.

At the time of this writing (July 2026), it is not possible to contact technical support directly. Need to contact general support and ask to connect with the technical team to resolve the issue. The general support team will then be able to assist.

MOTO payments aka Virtual Payment Terminal payments

You would need to ask the support team to enable the MOTO payments for this to work.
The way it was implemented for our client is to embed the Dojo card component within a modal.
To initiate the MOTO payment request, or ‘payment intent’ in Dojo terms, cardHolderNotPresent: "true" parameter needs to be passed to the API request. This parameter will tell Dojo API that the payment is specifically a MOTO payment.

You will then need to submit a go-live application, so make sure your implementation complies with all the requirements. One point to look out for is the requirement to implement the API refunds through the system.

Physical Payment Terminals

Steps to implementing the Physical Terminal Payments can be found in the Dojo step-by-step guide.

Physical Payment Terminal payments first need to be tested on the staging environment. Please contact Dojo support so they can set up test payment terminals on your account. In staging mode, you can not work with live terminals using a staging API key. The implementation is then presented to Dojo during the video meeting. After Dojo has approved the implementation and its compliance with their rules, they then assign the software-house-id, which can be used with live credentials. More on the software-house-id can be found here.

Just like with the MOTO payments above, there is a separate go-live checklist for the physical payment terminal payments. Make sure your implementation is in compliance.

Some of the required points that did not necessarily have been obvious from the documentation:

• It is mandatory to implement refunds with the physical payment terminals, not only API refunds;
• Card payments that require signature verification should provide the ‘Accept’ and ‘Decline’ options;
• When the payment is initiated via the API integration on the payment terminal, it is important to ping the /terminal-sessions/{terminalSessionId} API endpoint and display the latest message from the notificationEvents key on the API response. The API should be pinged regularly while the payment session on the physical payment terminal is still active.
• In the case of this implementation, the payment terminal is associated with the user account. Each user’s payment terminal is configured in the settings page. Dojo asked for the CRM users to be able to enter the manufacturer terminal ID, rather than the API terminal ID on the user settings page. The manufacturer terminal ID is tid in Dojo terms.

After receiving the live software-terminal-id, make sure you enable the Pay at Counter integration on the physical payment terminal. After this is enabled, payment terminals should become available to you through the Dojo terminal API endpoints.