FAQs | API Developer Portal

1. What is client id & secret and their use case?

Ans: They are used to verify the identity of users or applications that request access to the system. They play a crucial role in ensuring that only authorized individuals or systems can interact with the API.

2. Is different validation keys or client id & client secret required for different product?

Ans: The client id & client secret should be unique for different products until and unless the user name will be changed.

3. Does UAT validation keys are diff. from production and who will provide them?

Ans: Yes, UAT validation keys are different from the production ones. But when the products will be on-boarded or live they may be different. And the production details will be provided by iServeU.

4. What are the diff. details that will be provided for production?

Ans: The product url, client id and client secret will be provided for production.

5. How callback feature can be enabled?/ What is the callback receive time from iServeU after a transaction is completed?

Ans: For the callback feature to be enabled, you need to prepare a webhook API and share the URL with iServeU to get it configured. Once it is configured, you will receive callback for all the transactions. The format to configure the webhook API at your end is mentioned in the documentation of each product.

6. What is POS and what transaction modes are we accepting?

Ans: This device effectively utilizes the features and the APIs to ensure seamless transactions. iServeU Technology offers the most complex APIs to a common data model to speed up integration and flexibility that meets your business needs and new customer trends.
IMPS and NEFT transaction modes are accepting.

7. What is the service APK used for and how can we get it in production and staging?

Ans: The service APK (Android Package Kit) is a file format which is used to distribute and install applications on the Android operating system. In the context of any service-based app, the service APK refers to the mobile application package which provides specific functionalities related to the service, such as biometric authentication, financial transactions, user management, and more.

Service APK in Staging:

Purpose: A staging environment is used for testing the application in a setting that closely mirrors the production environment. This helps to identify and fix any issues before the application is released to the public.
Deployment: The APK is deployed to the staging environment, where it undergoes rigorous testing. This includes functional testing, User Acceptance Testing (UAT), security testing, and performance testing.

Service APK in Production:

Approval: Once the APK passes all the necessary tests in the staging environment, it is approved to release to the production environment.
Deployment: The final, tested version of the APK is deployed to the production environment. This can be done through various channels, such as the Google Play Store, direct downloads from the official website, or through an Enterprise Mobility Management (EMM) solution if it is for internal use within an organization.

8. What is the status check API and how frequently can we use the API?

Ans: The status check API is a type of application programming interface (API) used to verify the current status of a transaction, service, or any other operation within a system. In the context of financial services like mATM, a status check API might be used to verify transaction status, monitor service availability, track user requests.
The frequency of using the status check API depends on the following factors:

Service Provider's Policy
Transaction Volume
Operational Needs

Example Scenario for mATM
In the context of mATM, a status check API is crucial for verifying the status of transactions such as cash withdrawals, deposits, or balance inquiries. Here’s an example scenario illustrating how the API can be used effectively.

Scenario: Cash Withdrawal Transaction

Initiation: A customer approaches an mATM device to withdraw cash.
Transaction Request: The customer enters their Aadhaar number and authenticates using their fingerprint. The mATM sends a transaction request to the server.

9. What details are to be used for Android testing, and for UAT, who will provide the details?

Ans: For Android testing, as well as User Acceptance Testing (UAT), the necessary details typically include various technical and access information. These details are crucial to ensure that the testing environment closely mimics the production environment and that all functionalities are thoroughly tested before the final deployment.
Details Required for Android and Web SDK Testing:

API Endpoints
Authentication Tokens
SDK Documentation
Sample Data
Test Accounts
Environment Details
Configuration Files
Device Specifications
Error Reporting Mechanisms
Version Control

User Acceptance Testing (UAT) Details

UAT Environment
Test Scenarios and Cases
User Roles and Permissions
UAT Schedule
Access to Stakeholders
Feedback Mechanism
Acceptance Criteria

Providers of the details:

The development team is typically responsible for providing the technical details required for SDK testing.
The product management team usually provides the test scenarios, test cases, and acceptance criteria.
The Quality Assurance (QA) team helps in setting up the test environment, preparing test accounts, and ensuring that all test scenarios are covered.
The IT and operations teams are responsible for setting up and maintaining the UAT environment, ensuring it closely mimics the production environment.
Business users and stakeholders who will be involved in UAT provide insights into real-world usage and help validate that the system meets business requirements.

10. How does a retailer need to be onboarded under iServeU for doing any transactions and what checks do we have?

Ans: Only in production environment a retailer needs to be on-boarded. As per NPCI guidelines we do check & maintain negative registry, so before any retailer get onboarded we check their onboarding details. Once the data is verified, user/retailer get onboarded.
Negative registry checks:: negative PIN, PAN, ADDRESS

11. How do I get access to the UAT POS API?

Ans: To get access to the UAT POS API use their developer portal.

12. What are the prerequisites for using the POS API?

Ans: The only prerequisites to use the POS API are client credentials, for the UAT environment you get the credentials from the developer portal email.

13. Is there a sandbox environment for testing?

Ans:Yes, there is a sandbox environment available for testing the mATM SDK. This allows you to simulate transactions and test your integration before going live.

14. How do I authenticate API requests?

Ans:API requests are authenticated using API keys, which are included in the request headers. This ensures secure communication between your application and the mATM SDK.

15. What POS devices are supported by the SDK?

Ans:The SDK supports NPCI-compliant and RBI-approved POS devices from manufacturers such as:

WISEASY
MoreFun
PAX

16. Can the SDK handle both card and UPI-based payments?

Ans: Yes, the SDK supports card-based payments (chip-and-PIN, magnetic stripe, NFC) and UPI-based payments (QR code or UPI ID).

17. Is the SDK compatible with offline transactions?

Ans: No. The SDK does not support offline transaction recording.

18. How do we debug errors during integration?

Ans:The SDK provides detailed logs and error codes. Refer to the support team for assistance.

19. Does the SDK support integration with other iServeU services?

Ans: Yes, the SDK can be integrated with other iServeU services like AePS, BBPS, and UPI for a unified payment solution.

20. Can the SDK be customized for specific use cases?

Ans: Yes, the SDK allows custom configurations to meet unique business requirements, such as adding specific payment options.

21. What should we do if a transaction is stuck in a pending state?

Ans: The SDK retries pending transactions or reverses them automatically after a timeout. Ensure the device and network are functioning properly.