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 Here

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

Endpoints