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: 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.

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 POS, 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 POS
In the context of a POS system, the status check API is essential for verifying the status of transactions such as payments, refunds, or balance inquiries. Here’s an example scenario illustrating how the API can be used effectively.
Scenario: Payment Transaction

1. Initiation: A customer makes a purchase at a store and chooses to pay using their debit card via the POS terminal.
2. Transaction Request: The customer swipes their card and enters their PIN on the POS terminal. The POS system sends a payment request to the payment gateway server.

 

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 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 POS API use their developer portal.

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.

Ans: Yes, there is a sandbox environment available for testing the POS API. 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 POS API.