Triple Play Pay API
For developers who prefer their native language or who don’t have a development app that converts calls to REST, we offer robust Software Development Kits.
See Available SDKs HereUsing REST
Triple Play Pay API endpoints return secure JSON metadata that you can utilize for a personalized payment experience.
Base Address for Testing
For development testing in our protected Sandbox
environment, the base address of Web API is:
https://sandbox.tripleplaypay.com/
Base Address for Production
The base address of the API is:
https://tripleplaypay.com/
Requests
Each endpoint in our API has its own unique path.
Data is accessed and utilized via standard HTTPS requests in UTF-8 format to an API endpoint. Where possible, the API uses appropriate HTTP verbs for each action:
GET: Retrieves resources
POST: Creates resources
PUT: Changes and/or replaces resources or collections
DELETE: Deletes resources
Responses
Triple Play Pay API responses always include a JSON object. Explore the documentation under "Endpoints" in the navigation list on this page for endpoints and their responses.
Our standard response:
{
"status": true or false,
"id": "",
"message": result (json) or error message (string),
"method": endpoint called
}
Status Codes: Our API uses the following response status codes, as defined in the RFC 2616 and RFC 6585:
200 - OK
The request has succeeded. The client can read the result of the
request in the body and the headers of the response.
201 - Created
The request has been fulfilled and resulted in a new resource
being created.
202 - Accepted
The request has been accepted for processing, but the processing
has not been completed.
204 - No Content
The request has succeeded but returns no message body.
304 - Not Modified
400 - Bad Request
The request could not be understood by the server due to
malformed syntax. The message body will contain more
information.
401 - Unauthorized
The request requires user authentication or, if the request
included authorization credentials, authorization has been
refused for those credentials.
403 - Forbidden
The server understood the request, but is refusing to fulfill it.
404 - Not Found
The requested resource could not be found. This error can be due
to a temporary or permanent condition.
429 - Too Many Requests
Rate limiting has been applied.
500 - Internal Server Error
You should not come across any of these. Please report these to
us by posting in the GitHub discussion.
502 - Bad Gateway
The server was acting as a gateway or proxy and received an
invalid response from the upstream server.
503 - Service Unavailable
Again, you should not come across any of these. The server is
currently unable to handle the request due to a temporary
condition which will be alleviated after some delay. You can
choose to resend the request again. Please report these to us by
posting in the GitHub discussion.
Explore examples of API calls and JSON responses here in our GitHub.
Building for Accessibility
Designing and developing an app for accessibility ensures a
high-quality product that is usable by all from the very
beginning.
We believe that it is the responsibility of every stakeholder,
subject matter expert, and contributor involved in software
and web development to prioritize accessibility at every stage
of the development lifecycle.
We at Triple Play Pay hold ourselves accountable for creating
inclusive and accessible products by setting the priority from
conceptualization onward, including by continuously iterating to
improve accessibility. We expect the same standard of every
organization, stakeholder, and team member who utilizes our
products and/or API.
The below resources can be harnessed by all designers and developers as a baseline for quality in design and development.
Accessibility Fundamentals of A11y
World Wide Web Consortium (W3C)’s Web A11y Institute has
published the Fundamentals of A11y resource covering a range
of topics and in-depth contexts. View their additional checklist
here.
18F Accessibility Guide
The US Government’s 18F Accessibility Guide is a
user-friendly guide for all designers and developers that
utilizes the Web Content Accessibility Guidelines (WCAG).
See something in our products that doesn’t match these
standards?
Email us at: devteam@tripleplaypay.com
Sandbox & Development Certificate
For smooth integration and stakeholder satisfaction, Triple Play Pay has built a quick certification process that utilizes a test API Key in our Sandbox environment to ensure that developers have the resources and know-how to properly utilize our endpoints, requests, and responses for successful transactions and user experiences. Stakeholders can access a certficate page to keep track of which endpoint tests their developers have passed in our sandbox environment.
Go to the certification page >
Application of our API
Our payment processing API provides endpoints for common payment workflows like authorizing charges, settling authorized amounts, and tokenizing payment methods for future use. It also provides endpoints for more advanced functionality such as retrieving transaction history, uploading signatures and documents required for merchant onboarding, and more. Below are some key notes for use of the API endpoints.
Generating a Failed Charge
When processing charges, it's important to note that any transaction made with the Sandbox URL for $3.33 will fail. This is so that you can see the reponse for a failed transaction.
Duplicate Charge Catching
The API also has duplicate charge prevention enabled by default. If you submit multiple charges for the same amount on the same card or bank account within a single day, the second and subsequent charges will fail. If you need to process many similar charges in a short timeframe, you can request duplicate protection to be disabled for your account.
Authorizations for Future Charges
For authorizing a charge without completing it right away, use the "authorize" endpoint. This will check for available funds on the provided payment method. Once authorized, you can submit the "settle" or "charge" requests with the authorized amount to complete the transaction.
Saving Payment Details for Future Charges
To generate a tokenized version of a payment method like a card or bank account, use the "card" or "bankaccount" endpoint. The returned token can be safely stored and used for future "charge" requests.
GitHub
Great news! We’re open-source, open-discussion, and open for the success of organizations and developers everywhere.
In the GitHub Repository, you will find:
- source files
- release notes
- the full OpenAPI SDK variety for download
In the GitHub Discussion, you will find:
- sample code to help you with development
- a place to ask questions
- a place to share ideas