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.

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

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.

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

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.

Ans: Micro ATMs is card swipe machine through which banks can connect to their core banking system remotely. This device will be used to help your customers to have direct access to their bank account, and banking services like Cash Withdrawal, Balance Enquiry, mini statement etc.
IMPS and NEFT transaction modes are accepting.

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.

 

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:

1. Service Provider's Policy
2. Transaction Volume
3. 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

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

 

Ans: For Android and web SDK 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

1. API Endpoints
2. Authentication Tokens
3. SDK Documentation
4. Sample Data
5. Test Accounts
6. Environment Details
7. Configuration Files
8. Device Specifications
9. Error Reporting Mechanisms
10. Version Control

User Acceptance Testing (UAT) Details

1. UAT Environment
2. Test Scenarios and Cases
3. User Roles and Permissions
4. UAT Schedule
5. Access to Stakeholders
6. Feedback Mechanism
7. Acceptance Criteria

Providers of the details:

1. The development team is typically responsible for providing the technical details required for SDK testing.
2. The product management team usually provides the test scenarios, test cases, and acceptance criteria.
3. The Quality Assurance (QA) team helps in setting up the test environment, preparing test accounts, and ensuring that all test scenarios are covered.
4. The IT and operations teams are responsible for setting up and maintaining the UAT environment, ensuring it closely mimics the production environment.
5. 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.

 

Ans: Only in production environment a retailer needs to be on-boarded. As per NPIC 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

Ans: To get access to the UAT mATM SDK use their developer portal.

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

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.

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.