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: It is a kind of payment system that is based on a Unique Identification Number and enables financial transactions by Aadhar-based authentication effortlessly. You can transfer funds, deposit/withdraw cash, make payments, and much more. Aadhaar Enabled Payment System API is the best solution for Rural India.
IMPS and NEFT transaction modes are accepting.
Ans: Daily bio-auth or Daily Biometric Authentication refers to the use of biometric data (such as fingerprints, facial recognition, iris scans, or voice recognition) for verifying the identity of individuals on a daily basis. This technology is commonly used in various sectors for different purposes, including: Banking and Financial Services, Workplaces, Mobile Devices and Computers, Healthcare, Government Services etc.
By using daily bio-auth, AEPS ensures a secure, accessible, and efficient method for individuals to perform banking transactions, thereby fostering greater financial inclusion and trust in the banking system. Daily bio-auth is used for several reasons like Enhanced Security, Convenience and Accessibility, Financial Inclusion, Real-time Transactions, Eliminating Identity Fraud, Compliance and Regulatory Requirements etc
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.
- 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 AEPS, 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 AEPS
In AEPS, after initiating a cash withdrawal or fund transfer, the application might use the status check API to confirm if the transaction has been processed. The frequency of these checks might start at every few seconds immediately after the transaction initiation and then gradually reduce to longer intervals until the transaction status is confirmed.
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
- API Endpoints
- Authentication Tokens
- SDK Documentation
- Sample Data
- Test Accounts
- Environment Details
- Configuration Files
- Device Specifications
- Error Reporting Mechanisms
- Version Control
- UAT Environment
- Test Scenarios and Cases
- User Roles and Permissions
- UAT Schedule
- Access to Stakeholders
- Feedback Mechanism
- Acceptance Criteria
- 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.
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
Ans: To get access to the UAT AEPS SDK use their developer portal.
Ans: The only prerequisites to use the AEPS 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 AEPS 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 AEPS SDK.