Hello World! We provide a state-of-the-art modular API platform for you to build Fintech products with seamless money flow. Just dive into our API documentation to get a jumpstart on your Fintech product journey.
If you are in the mood to explore, experience our APIs in our online Sandbox that has no effect on your live data or interaction with banks/card networks. Explore and choose the flow that suits your needs.
Browse through the Libraries section for sample code snippets, checkout the FAQs and if you still have any questions, feel free to write to email@example.com
Our API platform is built on the base of REST architecture or also known as the Representational State Transfer framework. We offer resource-based URLs that accepts JSON or form-encoded requests. The response is returned as JSON-encoded responses by using Standard HTTP response codes, verbs, and authentication.
Go for the "Run" button to experience our APIs right away or copy the link to import as Postman Collection and take-off!
Once you sign up, you will receive a set of API keys via email to authenticate requests. Each API key is valid only for a specific time frame. In case you lose them or need a fresh set of keys, just head over to your dashboard and generate one.
These keys are only for initial testing (using cleartext) in our Sandbox. Once you complete the initial testing, then you need to upgrade to our Pre-Prod environment.
Our Pre-Prod environment uses a mix of keys/certificates based on mutual authentication. At this stage, we require a bit more information about your server's IPs, certificates, and so on
You also need to specify a set of attributes that you want to integrate with the product. Once we assimilate the necessary information, our support team will deploy a custom Pre-Prod environment suited to your requirements
Once the product reaches the production stage, all API calls will be authenticated using the Keys/Certificates based on mutual authentication.
Here again, you might need to provide a similar set of information to obtain the authentication parameters.
Along with this set-up, we will also provide the required Authentication parameters and Security framework. You might need to develop these two factors to suit your production environment
The online sandbox could be accessed without a separate security implementation. However for the Pre-Prod and Production environments, all API calls will be authenticated using key based mutual authentication
If you have completed integrating our APIs in your application you may start testing using the Pre-Prod environment.
Your Source IPs would be whitelisted in our Firewall. As per PCI Standards, all communications with YAP APIs are allowed only through TLSv1.2 version. If your server still uses older versions of SSL/TLS you must upgrade to use our APIs.
The entire API payload would be encrypted end-to-end using the steps outlined in the YAP Security framework document which will be shared to you.
In a nutshell, the payload originating from your end must be encrypted using a mix of our public key and vector, signed using your private key. YAP Authentication engine would verify your signature using your public key and decrypt the payload using our private key. Inverse of this process would be followed for API response
The commonly used message structure for HTTP request headers & payload
The request format, which is required for operations with a request body. The syntax is: application/json
Content-Type: application/ < format >
This section provides the compilation of error messages generated by the system. You may choose to display a user friendly message.
Client’s system needs to look out for the following fields in the error message, as these fields will contain the details of the error.
If any other error received, Client needs to raise a ticket with YAP and will be serviced appropriately.
At YAP we lean towards creativity at all times. There are several ways an integration to our APIs could be implemented. We have handpicked the most used languages to provide sample libraries which would act as a starting point in your Fintech product building journey.
We are always looking at ways to improve the developer experience and if you think you have a better way of implementing our APIs we would be happy to collaborate and, with your consent, showcase your library as a sample. Let us know!
YAP is Your API Platform that helps you build customized products to suit your business needs. We have envisioned flows across Payments, Banking and Lending which cater to most Fintech use cases as described here
We work with leading issuers in India, Middle East, SEA, Australia and New Zealand. Bank of Baroda, ICICI Bank, RBL Bank, YES Bank, DCB Bank, Ola Financial Services to name a few in India. To know more about our partners click here.
The Transactions endpoint returns data elements including current and available balance, name of the user’s bank account, transaction pending status, geo-coordinates of transaction location, transaction categorization, and a statistical confidence score for category and location. If there’s something else you’d like to see, we’d love to hear from you. Share your feedback and get answers to any additional questions you have about our products and your data needs by contacting our team.
If your business requires you to handle card data, you may be required to meet an exhaustive list of security controls as per Payment Card Industry – Data Security Standards (PCI-DSS). There are thousands of pages of documentation about PCI DSS and hundreds of pages of forms to fill for validating your security controls. This is easier said than done and you may have to deploy several resources to manage and document this activity. Simply reading through the documents would take several weeks, let alone implementing it!
PCI DSS is the global security standard for all entities that store, process, or transmit cardholder data and/or sensitive authentication data. PCI DSS sets a baseline level of protection for consumers and helps reduce fraud and data breaches across the entire payment ecosystem. It is applicable to any organization that accepts or processes payment cards (Visa/MasterCard/Amex/Discover/Diners)
PCI DSS compliance involves 3 major steps:
Some businesses require handling of sensitive card data to fulfill certain functionalities or to provide better user experience. Businesses that handle such data are required to meet each of the 300+ security controls in PCI DSS. There is no two ways about this process, even if the data passes through the system for a jiffy we still need to implement all security controls. If you would like to avoid such overheads you may consider using our PCI Widgets instead of handling the card data in your system.
If your business does not need to handle card data you would still need to comply with a minimum set of PCI and OWASP guidelines which would enhance the security of your system.
Businesses that handles or stores card data, needs to define the scope of its cardholder data environment (CDE). PCI DSS defines CDE as the people, processes and technologies that store, process, or transmit credit card data—or any system connected to it. Since all 300+ security requirements in PCI DSS apply to CDE, it is imperative to have segmentation between the payment environment from the rest of the systems to limit the scope of PCI validation. Without demarcation of CDE and Non-CDE systems the PCI validation scope would broaden and you would end up spending more time, effort, resources and in-turn huge costs.
PCI-DSS compliance is a continual activity that requires the controls to be tested quarterly. Businesses that comply with PCI DSS need to revalidate the controls and undergo audits annually without any exceptions. If you skip revalidation, you may risk being flagged off as Non-Compliant by entities that mandate PCI compliance.
Secure Cardholder Data
Information Security Policy and Procedures
Businesses that annually process over 6 million transactions of Visa or MasterCard, or declared as Level 1 by Payment Networks
Level 2, 3 and 4
Businesses that annually process between 1-6 million transactions, less than 1 million transactions and less than 20k transactions respectively
To simplify PCI compliance, the PCI council has released 9 Self-Assessment Questionnaires (SAQs) that are a subset of the entire PCI DSS requirement. Choose the most relevant SAQ applicable as per your business construct. A PCI-council approved QSA needs to check if each requirement has been met.
At YAP, we believe in making complex simple, we have chalked out a simple plan for your business to be PCI compliant. We have built PCI-Widgets for key elements like displaying Card Data, CVV, PIN set/reset. The primary goal of the PCI-Widget is for businesses to offer the features related to CHD without the need to process any related data through their systems. YAP PCI-Widgets are available as simple Web based (iFrame) snippets to ensure ease of use in a variety of front-end interfaces like Website, Mobile-site, Android and iOS apps.
With simplified SAQs and PCI widgets, YAP aims to turn your PCI compliance into a mere formality. For Fintech startups, it would save boatloads of work and for established players it can result in huge savings on resources – both people and systems.
To all our clients and partners, regardless of how we integrate, we would be happy to guide in navigating the complexities of PCI DSS. We will advise on which PCI form to use and how you can tackle your compliance overhead.
In case you need to undergo a full-fledged PCI-DSS compliance exercise we have established relationships with leading PCI QSA organizations and can get your compliance expedited.