Get Started

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 apisupport@yappay.in

Architecture

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!

YAP Architecture

Authentication

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.

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

Production Environment

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

Security

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

Message Structure

The commonly used message structure for HTTP request headers & payload



HTTP request headers

Authorization
AuthenticationData
Content-Type
application/json
TENANT
YAP to Provide

Payload

Request Method
POST/GET
Content-Type

The request format, which is required for operations with a request body. The syntax is: application/json

Content-Type: application/ < format >

Error Message

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.

  • detailMessage
  • shortMessage

If any other error received, Client needs to raise a ticket with YAP and will be serviced appropriately.

YAP Platform Error Codes

Code Message
Y101
OTP expired please regenerate OTP
Y102
Your maximum attempt exhausted
Y103
Invalid OTP
Y104
Data Exception
Y105
Mandatory field {0} is missing
Y106
{0} already exists
Y107
Could not find Validator
Y108
{0} cannot be edited by this service
Y109
Invalid Customer Id
Y110
Yap code is Invalid
Y201
Transaction failed please retry
Y202
Invalid Data
Y203
Push to GCM failed please Retry
Y204
YAP System validation failed
Y205
Invalid Merchant
Y206
Invalid Card Number
Y207
Card Number / Kit Number mismatch
Y208
Card already allocated
Y209
Business kit Mapping not found
Y210
Invalid Wallet ID
Y211
Wallet Id for {0} is missing
Y212
Insufficient Balance
Y213
Card Number already activated
Y214
Kit No Already Exists
Y215
Product not found
Y216
Not a registered mobile No.
Y217
YAP System processing error
Y218
No Customer exists for Business Id
Y219
Business ID cannot Be null
Y220
Business Type cannot Be null
Y221
At least “To Wallet Id” or “Business Id” should be valid
Y222
Wallet for criteria not found
Y223
Transaction ID {0} is invalid
Y224
The Entity {0} is blocked from transaction
Y225
Could not block entity
Y226
Entity Id Invalid
Y227
Kit not assigned
Y228
Not enough balance in the account
Y229
Invalid profile id
Y230
Authentication Failed
Y231
Account Provider is Invalid
Y300
Security exception

Libraries

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!

FAQs

What are YAP's products?

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

Who are our partner banks?

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.

What type of information does YAP provide via Transactions?

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.

A guide to PCI-DSS Compliance

Why do you need PCI Compliance?

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!

What is PCI-DSS?

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:

  • Handling Data- Handling the inflow and outflow of card data and ensuring that sensitive card details are collected and transmitted securely
  • Storing Data- Storing data securely as outlined in the 12 security domains of the PCI standard, such as encryption, ongoing monitoring, and security testing of access to card data
  • Validating Controls- Validating annually that the required security controls are in place, which can include repeating filling of forms, audits by external qualified security assessors
Handling card data

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.

Storing data securely

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.

Continual validation

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.

List of PCI-DSS controls

Secure Network

  • Install and maintain a firewall configuration to protect cardholder data
  • Do not use vendor-supplied defaults for system passwords and other security parameters

Secure Cardholder Data

  • Protect stored cardholder data (CHD)
  • Encrypt transmission of CHD across open or public networks

Vulnerability Management

  • Malware and Antivirus protection for all systems
  • Application VA/PT and Code reviews

Access controls

  • Restrict access to CHD on need-to-know basis
  • Authentication and Authorization for access to system components
  • Restrict physical access to CHD

Monitoring

  • Network monitoring and testing of all resources that processes CHD
  • Continual testing of security systems and processes

Information Security Policy and Procedures

  • Maintain Information Security Policies and Procedures applicable for all personnel.
Levels of PCI-DSS Compliance

Level 1

Businesses that annually process over 6 million transactions of Visa or MasterCard, or declared as Level 1 by Payment Networks

Requirements

  • Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA)
  • Quarterly network scan by Approved Scan Vendor (ASV) and all applicable controls

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

Requirements

  • Annual PCI DSS Self-Assessment Questionnaire (SAQ)
  • Attestation of Compliance by QSA
  • Quarterly network scan by Approved Scan Vendor (ASV)
What is Self-Assessment?

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.

How YAP helps businesses with PCI DSS compliance?

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.

PCI Level Avg PCI-DSS Certification Audit Time Avg Time using YAP PCI-Widgets Full Certification with YAP’s Partner QSAs
Level 1
4-6 months
0 days
30 days
Level 2
2-3 months
0 days
15 days
Level 3
1-3 months
0 days
7 days
Level 4
1-3 months
0 days
5 days