B2B API

Products
B2B API Integration Guide
gateway

API Version

Getting Started

Introduction

The B2B API is a powerful solution that enables any software developer to integrate PayTrace services into their proprietary software. Developers can use the B2B API to add payment processing in real time to any site or application by seamlessly integrating HTTPS Post requests. The API also goes beyond payment processing, offering the ability to store customer and transaction profiles, effortlessly generate email receipts, process recurring payments, automate accounts receivable, and more.

Sign up for a free sandbox account and Integrator ID

Contact us to request sandbox credentials that can be used for testing in a test environment. Once your sandbox account is approved, you will receive your integrator_id and sandbox credentials within 5 business days.

Once you have your sandbox credentials and integrator ID, you can use this Integration Guide and the API Specification linked below to build your integration.

Download the API Spec

Best Practices

Do not use the same API username and password from your Sandbox to Production accounts and vice versa.

Understanding Integrator IDs

Integrator IDs are not specific to any individual account but are associated with the integration itself. They help PayTrace identify which merchant accounts are using a particular integration. For instance, if an ISV partner builds a WooCommerce plugin for PayTrace, every merchant using this plugin will share the ISV partner’s integrator_id. This ID serves as a reference, informing PayTrace about the merchants utilizing the specific integration

Sandbox vs. Production Reminder

When development and testing are complete, you are ready to go live with your production account. Don’t forget to do the following:

1. Switch sandbox endpoints to the production endpoints.
2. Switch API user credentials from Sandbox to Production credentials.

If you do not have a production environment please contact us.

JSON API

This JSON API is designed as a REST API (Representational State Transfer). It has predictable responses and dedicated URLs for each method. This API utilizes OAuth 2.0 for authentication and authorization. It has HTTP verbs and HTTP response codes to provide the integrators and developers the fastest and most secure methods to integrate with our platform. JSON will be returned in all responses from the API, including errors with PayTrace defined error codes.

API Endpoints

All production API requests are made to https://api.paytrace.com. All sandbox API requests are made to https://api.sandbox.paytrace.com. All requests are served over HTTPS using TLS 1.2.

PayTrace Help Documentation

Explore the PayTrace Help Documentation for essential tools and knowledge, empowering you to maximize the effectiveness of the PayTrace Virtual Terminal. Unlock valuable insights and resources to enhance your user experience. Dive in to discover how to make the most of PayTrace’s features and capabilities.

Data Wrapped Responses

All responses are wrapped in a data-wrapper. This means for any of the documented response schemas, you will find the schema nested under the data property of the response itself.

Example
JSON 
{
	"status": "success",
	"status_code": 201,
	"data": {
		"access_token": "eyJ...4sA=",
		"refresh_token": "eyJ...n_v4sA=",
		"token_type": "Bearer",
		"expires_in": 900,
		"refresh_expires_in": 3600
	}
}

In this case, the content of response.data would match the response schema defined in the API specification. If using language level schemas, this may be an important consideration. In all cases, the status_code property should match the HTTP status code sent.

Schemas

All schemas (and endpoints) are available and conform to the OpenAPI 3 spec. You can view the OpenAPI schema in your browser or download it from the Resources page. This endpoint does not require authentication, and can be integrated programmatically into your custom solutions.

Request Headers

Please note that the following Request Header settings remain consistent through all API Methods except Authentication Token request.

Response Codes

The response_code plays an important role to determine if a requested API method is successful or not. It is highly recommended to check its value if writing a custom implementation (if checking manually, response_message or other API return data will often have a human readable description of what happened, however the message value may change over time, while the code will not). A sample of a data-wrapped response containing a response_code is as follows:

Example
JSON 
{
	"status": "success",
	"status_code": 200,
	"data": {
		"response_code": 101,
		"response_message": "Your transaction was successfully approved.",
		"transaction_id": "123456789",
		"approval_code": "999999",
		"approval_message": "APPROVAL 999999",
		"avs_response": null,
		"csc_response": null,
		"masked_card_number": "xxxxxxxxxxxx5454",
		"discretionary_data": null,
		"emv_details": null
	}
}

The response_code will contain one of the following codes with an associated response_message:

AVS and CSC Response

An approved transaction does not guarantee that the customer who provided the billing information is truly the card holder. Preventing fraud is paramount in the payment processing industry for multiple reasons, primarily minimizing merchant exposure to chargebacks and strengthening customer confidence in electronic payments.

Depending on your style of business and potential for chargeback exposure, PayTrace encourages you to validate each transaction’s fraud indicators, in addition to approval response, to verify if a transaction is legitimate and should be settled.

AVS (Address Verification System) and CSC (Card Security Code) Responses are excellent indicators to verify that your customer is the true card holder. Therefore, it is recommended to validate the AVS and CSC Responses against the following potential responses to determine if the appropriate fraud prevention features have been met before settling a transaction.

Here are the possible values for avs_response and csc_response parameters.

AVS Response

• Full Exact Match
• Address Match Only
• Zip Match Only
• No Match
• Address Unavailable
• Non-US Issuer does not participate
• Issuer System Unavailable
• Not a Mail/Phone Order
• Service Not Supported

CSC Response

• Match
• No Match
• Not Processed
• Not Present
• Issuer Does Not Support CSC

If you are processing an American Express transaction (15 digit card number starts with 37) and you provide a CSC value, the CSC Response will be empty. Note that American Express does not approve transactions whose CSC value is invalid.

Visa, MasterCard, Discover, and Diner’s Club will return a CSC Response.

JCB does not support CSC.

Error Responses

Example
JSON 
{
	"status": "error",
	"status_code": 422,
	"data": [
		{
			"detail": "Please send the e2ee encrypted value.",
			"type": "VALIDATION",
			"code": "E2EE_REQUIRED",
			"field": "body/csc",
			"error_id": null
		}
	]
}

The detail is a human readable message similar to response_message on a success. The type is a grouping of errors - in this case, a basic validation error. The code is an immutable value that can be implemented against. For some error types, in particular VALIDATION, the field will be a property path (similar to an XPath) that indicates what value property was wrong. Depending on the type of error, error_id may be filled out - this will often correspond to the response_code that indicates an error on the prior section.

Error Codes

The potential error object error_id values are as follows:

Testing Information

For API testing and integration, make sure to check following:

1. You have a valid account with API module enabled. PayTrace recommends testing in a Sandbox account prior to testing in a live environment.
2. Make sure to set and be aware about your account security settings from the PayTrace Virtual Terminal.
3. You server side code submits a valid authorization token in the expected format. See the Authentication section for more information.
4. Your API requests should have at least the required request parameters to avoid errors.
5. Your code can handle HTTP errors and API errors gracefully. See the Error Responses section for more information.

Test Data

The following data can be used to test in the sandbox environment. Note that using this data in a live environment will result in declines.

Testing Credit Cards

*Any valid expiration month and year will work as well.

Testing CSCs

Testing Addresses for AVS Response

Testing Amount

Configuring Security Settings

After receiving your sandbox credentials, you must configure your sandbox account to match your anticipated production account. To do so, log in to PayTrace and select the Security Settings tab under the Account Tab. Please see the Account Security settings here for more information regarding PayTrace Security Settings.

Setup

1. Send an authentication request with your API user credentials to generate an access token.
2. Prepare the request using an access token and test data. Submit the request to one of the API methods.
3. For API errors, see the PayTrace Virtual Terminal → Integration → API log. Look at the API Log for more details.

Creating API Credentials

Log in to the PayTrace sandbox application with Virtual Terminal using your admin web username and password.

Creating API User Credentials Best Practices

Do not use any special characters within your username and password. Alphanumeric only.

Permissions

Use the Select All button under Permissions to allow your API user to manage everything within the integration. If you do not do this, you may run into processing issues.

Authentication

The PayTrace JSON API requires authentication and authorization to make all the requests. The PayTrace JSON API uses OAuth 2.0 for Authentication and Authorization.

OAuth 2.0 provides a "client_credentials" grant type that can be used to exchange a username and password for an access token directly. If you decide not to use any of the 3rd party OAuth 2.0 libraries, the following steps are needed :

1. You can simply make a request to our API with your API account user credentials and get the Bearer access token.
2. Then use the Bearer Access token in an Authorization Header along with other settings to make any further API request provided with this documentation. For more information, see the Request Header section.

To initiate the transaction request, you will need to make calls to two API endpoints.

The first call is to authenticate. You can make this call using a variety of server-side languages or libraries of your choice. Here are the details for this request:

Method: POST

Request URL: https://api.sandbox.paytrace.com/v3/token/

CURL Example
shell 
curl 'https://api.paytrace.com/v3/token' -XPOST -H'Content-Type: application/x-www-form-urlencoded' -data-raw 'grant_type=client_credentials' -data-raw 'client_id=YourApiUsername' -data-raw 'client_secret=YourApiPassword'

Request Body
JSON 
{
	"username": "YOUR USERNAME",
	"password": "YOUR PASSWORD",
	"grant_type": "client_credentials",
	"integrator_id": "YOUR INTEGRATOR ID"
}

Authentication Error Example

The following error response will be returned when sending incorrect user credentials with HTTP status code 401-Unauthorized.

Authentication Error
JSON 
{
	"error": "invalid_grant",
	"error_description": "The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client."
}

Authentication Successful Response

When authentication is successful, you will receive a JSON response which includes an "access_token" field. The value in this field will be used in the next step.

How to utilize the Authentication token in the Authorization header

Once you get the Authentication token, you can submit the token_type and access_token as values in the Authorization Header of your API request.

Authorization Header format

The authentication format is Bearer access_token.

Authorization Successful Response

The following response will be returned with HTTP Status code 200 OK.

Successful Response
JSON 
{
	"access_token": "4656d6f6132333:4656d6f6132333:2b607b9a44720c9c3ca867653c7e6ef8b3f3802709c17f2a54402820d155f214",
	"token_type": "bearer",
	"expires_in": 7200,
	"created_at": 1489710779
}

Each API request requires authentication via the access token described earlier.

Authentication Errors Summary

Grant Type: Client Credentials or Refresh Token

Status Updates and Communications

To receive notifications whenever PayTrace creates an incident, updates an incident, resolves an incident or changes a component status, sign up for the Status Page . Notifications are available via webhook, text and email.

To stay up to date with PayTrace product updates & features, webinar schedules & registration, payment industry jib jab, plus random contributions of PayTracer culture, talent, and in-house happenings, we encourage you to subscribe to our Blog.

e2ee Client-Side Library

The PayTrace End-to-end-encryption (e2ee) Library supports client-side encryption of sensitive data, reduces merchant's and integrator's exposure to PCI-compliance verification. Sensitive data can be encrypted at the user's web browser using The PayTrace JavaScript E2ee Library. The encrypted data can only be decrypted by PayTrace. The merchant or the integrator has no access to the original sensitive data. It helps to ensure that sensitive data remains unreadable in as many locations as possible. Primarily card data (credit and debit) and other sensitive data points fall into this category.

In contrast to earlier API versions, all data points noted as e2ee are required to be encrypted before being sent to this API.

The benefits of using the PayTrace Client-Side E2ee Library

1. It will allow your customers to process transactions on your website.
2. Your customers are not required to be redirected to another payment page.
3. It provides your customers the comfort and security of processing payments on your website.
4. Utilizing this Library reduces your PCI scope

Encryption Details

The sensitive data is encrypted before the web form is submitted and until it is received at PayTrace's secure server. The RSA public/private key pair is used to encrypt sensitive credit card data. The public key corresponds to API E2ee Public key endpoint. It will be used to encrypt the sensitive data. Only PayTrace can decrypt the encrypted data with the private key.

How to utilize the PayTrace Client-Side Encryption Library

1. Incorporate The PayTrace Client-Side Encryption Library in a web form.
2. Get the encrypted field value with your server side code.
3. Submit the encrypted values to the API calls.

How to incorporate the PayTrace Client-Side E2ee Library in a web form?

The following steps are required to utilize The PayTrace Client-Side E2ee Library in a web form.

1. Setup: Include The PayTrace E2ee Library using script tag in a header section.

   Example
   HTML 
   <head><script src='https://api.sandbox.paytrace.com/v3/assets/js/e2ee/paytrace-e2ee.js'></script></head>
   

2. For the sensitive data fields that should be encrypted at the browser, add the "pt-encrypt" class.

   Example
   HTML 
   <body><div id='cc-data'><input type='text' class='form-control pt-encrypt' id='ccNumber' name='ccNumber' placeholder='Credit card number'><input type='text' class='form-control pt-encrypt' id='ccCSC' name='ccCSC' placeholder='Card security code'></div></body>
   

3. Submit a form with any of the following scenarios.
   1. Bind the submit event of the form to the PayTrace Client-Side E2ee Library.

      Example
      HTML 
      <script>$(document).ready(function() {paytrace.setKeyAjax('https://api.sandbox.paytrace.com/v3/e2ee/public-key.pem');});</script>
      

   2. Or submit a valid form to the PayTrace Client Side E2ee Library. You will need to validate your form with your own implementation first and then submit the valid form. However, you will need to set the key with paytrace.setKeyAjax(url) method before a valid form is submitted.

      Example
      HTML 
      <script>$(document).ready(function() {paytrace.setKeyAjax('https://api.sandbox.paytrace.com/v3/e2ee/public-key.pem');});$('#myform').submit(function(e) {e.preventDefault();if ($(this).valid()) {paytrace.submitEncrypted(this);} else {console.log('INVALID FORM. Your code for further action here');}return false;});</script>
      

How to submit encrypted values to the API

Once you have received the encrypted values on the server side with form submission, submit them using an API Request. No additional request parameters are needed to prompt the API to accept the encrypted values. This API accepts encrypted values only. For example, the credit card number will assigned card.number, the CSC will be assigned to csc.

Protect.js

In today’s world, security and PCI compliance play important roles in protecting cardholders and delivering cash flow for businesses.

Protect.js uses an iframe to create PayTrace hosted fields when collecting sensitive-payment information. This allows you to control the UI and UX of your checkout process so that cardholder data never touches your servers.

You can quickly start accepting secure payments and storing cardholders’ payment information by embedding a few lines of code within your existing checkout flow while achieving the highest level of PCI-Compliance, SAQ-A.

The benefits of using PayTrace Protect.js

1. It will allow your customers to process transactions on your website.
2. It will allow your customers to safely and securely store their credit card information for future use.
3. Your customers are not required to be redirected to another payment page.
4. It provides your customers the comfort and security of processing payments on your website.
5. Using Protect.js reduces your PCI scope and can help you qualify for PCI SAQ-A.

The PayTrace Protect.js Workflow

Protect.js Details

Protect.js places PayTrace Hosted Payment fields within an iframe on your webform. This will allow your customers to enter their sensitive credit card information directly into PayTrace while ensuring your server does not handle any sensitive data. Once this information has been captured, Protect.js will then return a one-time-use hpf_token (nonce) and enc_key. The nonce and enc_key can then be submitted via an API request in order to process transactions or create customer profiles.

How to incorporate Protect.js in a web form

The following steps are required to utilize The PayTrace Protect.js Library in a web form. Our examples make use of Promises and Arrow Functions which are not supported by IE11. For integrators wishing to support IE11, you will need to use Callback Functions and methods. For assistance, please contact our dedicated Developer Support team.

1. Setup: Include the JS library and div container tag for iframe on your website. Please refer to the code sample:

   Example
   HTML 
   <!-- This is the PayTrace Protect.js library: --> 
   <script src='https://protect.paytrace.com/js/protect.min.js'></script> 
   <!-- This is the PayTrace Sandbox Protect.js library: --> 
   <script src='https://protect.sandbox.paytrace.com/js/protect.min.js'></script> 
   
   <!-- The JS Library then adds the iframe using this div container tag during setup -->
   <div id='pt_hpf_form'><!--iframe sensitive data payment fields inserted here--></div>
   

   This step allows the PTPayment object to become available when the Protect library script is sourced in the web application. See the available PTPayment methods below.

   Toggle PTPayment Methods

   Method	Description
   process	Validates and tokenizes Hosted Payment Field Data
   setup	Initializes the Protect.js Hosted Payment Fields within iframe using the clientkey. Styling options can be statically applied during the setup call. For more information regarding our styling options, see Styling Options.
   validate	Validates Hosted Payment Field input prior to tokenizing data. Takes function as an argument.
   reset	Clears Hosted Payment Fields and resets Protect.js to its beginning state.

2. Get authorization for the application to use the JSON API. Make an OAuth authorization call to the JSON API to get an API AUTH TOKEN. This token will be used as the authorization bearer access token to authorize the application to use PayTrace’s API. The token should be kept secret and should never be added to client side code. This token is valid for 2 hours.

   Example
   Shell 
   grant_type=client_credentials&client_id=YourUserName&client_secret=YourPassword
   

   See the Authentication section for more information about how to generate an Oauth Token.

3. Use the JSON API Authorization token to get authorization to use Protect.js using the API AUTH TOKEN from step two as the authorization header. Make a JSON API POST request to: https://api.paytrace.com/v3/payment_fields/token/create to get a PROTECT AUTH TOKEN (clientKey). The clientkey will be used to authorize the application to use Protect.js. This key is valid for 20 minutes.

   Example
   CURL 
   POST 
   URL='https://api.paytrace.com/v3/payment_fields/token/create' 
   Content-Type: application/json 
   Authorization: Bearer "Auth Token in Step 2"
   

4. Use the Protect authorization token to set up the payment form. Please refer to the code sample:

   Example
   HTML 
   <script> 
   	// Minimal Protect.js setup call 
   	PTPayment.setup({ 
   		authorization: { clientKey: <clientKey> } 
   	}).then(function(instance){ 
   		//use instance object to process and tokenize sensitive data payment fields. 
   	});
   </script>
   

   By this point, you should be able to see the Protect.js iframe rendered on your webpage. See the example below:

   To improve the look and feel of Protect.js, styling options can be statically applied during the setup call. For more information regarding our styling options, see the Protect.js Styling section.

5. Bind the submit event to an event handler for the tokenization of sensitive data. The process method will tokenize the sensitive data in the payment fields. The method returns an http promise that will either be fulfilled (resolved) or rejected. If it is rejected, the possible reasons are: network error, internal error, or the fields did not pass validation.
   1. Validate the fields before tokenizing sensitive data. PTPayment.validate will validate the payment fields and allow you to re-prompt your customers to enter valid information.

      Dynamic styling can then be used to better control your customer experience when invalid input is entered. For more information regarding our styling options, see the Protect.js Styling section.

      For a list of potential validation errors, see the Validation Error Responses below. Please refer to the code sample:

      Example
      JS 
      // this can be any event we chose. We will use the submit event and stop any default event handling and prevent event handling bubbling.
      document.getElementById("ProtectForm").addEventListener("submit",function(e){
      	e.preventDefault();
      	e.stopPropagation();
      	// To trigger the validation of sensitive data payment fields within the iframe before calling the tokenization process:
      	PTPayment.validate(function(validationErrors) {
      		if (validationErrors.length >= 1) {
      			if (validationErrors[0]['responseCode'] == '35') {
      				// Handle validation Errors here
      				// This is an example of using dynamic styling to show the Credit card number entered is invalid
      				PTPayment.style({'cc': {'border_color': 'red'}});
      			}
      		} else {
      			// no error so tokenize
      			instance.process()
      				.then( (r) => submitPayment(r) )
      				.catch( (err) => handleError(err) );
      		}
      	});// end of PTPayment.validate
      });
      // end of add event listener submit
      

   2. Or directly tokenize sensitive data. The tokenization process also validates the sensitive data payment fields. Dynamic styling can then be used within the error handling to better control your customer experience when invalid input is entered. For more information regarding our styling options, see the Protect.js Styling section.

      For a list of potential validation errors, see the Validation Error Responses below. Please refer to the code sample:

      Example
      JS 
      // this can be any event we chose. We will use the submit event and stop any default event handling and prevent event handling bubbling.
      document.getElementById("ProtectForm").addEventListener("submit",function(e){
      	e.preventDefault();
      	e.stopPropagation();
      	// The tokenization process also validates the sensitive data payment fields
      	PTPayment.process() //call tokenization
      		.then( (r) => submitPayment(r) )
      		// submit nonce and cipher key to PayTrace Protect Servers to tokenize sensitive data payment fields
      		.catch( (err) => handleError(err) );
      		// handle unsuccessful tokenization failures
      	});
      // end of add event listener submit
      

Validation Error Responses

If for any reason the users input fails the Protect.js validation, the appropriate response code will be returned in the error response.

Toggle Response Codes

How to submit Protect.js Tokens through the API

Once you have received the hpf_token (nonce) and enc_key, you will then submit these values using an API request and the Oauth token from Step 2. API methods that are meant to be used with the Protect.js UI are listed within their appropriate request categories and begin with the keyword Protect.

Toggle API Methods

Successful Protect.js tokenization response
JSON 
{
	"success": true,
	"message": {
		"hpf_token": "f519084b-db08-4e82-8670-9e690d9897cc",
		"enc_key": "84jkunZs5Ae4_tNaW3QtIIjaE08wyg70oJfA-gtm6aY="
	}
}

Protect.js validation error response
JSON 
{
	"message": "Field Validation Error(s)",
	"reason": [
		{
			"description": "Please provide a valid Credit Card Number.",
			"responseCode": "35"
		},
		{
			"description": "Please provide a valid Expiration Month.",
			"responseCode": "43"
		}
	]
}

Protect.js Styling

Protect.js allows you to style the Hosted Payment Fields to best fit your website. Styling can be applied either statically, during the setup method call, or dynamically during runtime.

Static Styling Options

The following options are available during the Protect.js setup phase.

Styleable Fields

NOTE: Only background_color can be modified.

Styling Options

Static Styling Example

PTPayment.setup({
 styles:
  {
   'code': {
    'font_color':'#5D99CA',
    'border_color':'#EF9F6D',
    'border_style':'dotted',
    'font_size':'13pt',
    'input_border_radius':'10px',
    'input_border_width':'2px',
    'input_font':'serif, cursive, fantasy',
    'input_font_weight':'700',
    'input_margin':'5px 0px 5px 20px',
    'input_padding':'0px 5px 0px 5px',
    'label_color':'#5D99CA',
    'label_size':'16px',
    'label_width':'150px',
    'label_font':'sans-serif, arial, serif',
    'label_font_weight':'bold',
    'label_margin':'5px 0px 0px 20px',
    'label_padding':'2px 5px 2px 5px',
    'label_border_style':'dotted',
    'label_border_color':'#EF9F6D',
    'label_border_radius':'10px',
    'label_border_width':'2px',
    'background_color':'white',
    'height':'25px',
    'width':'110px',
    'padding_bottom':'2px'
   },
   'cc': {
    'font_color':'#5D99CA',
    'border_color':'#EF9F6D',
    'border_style':'solid',
    'font_size':'13pt',
    'input_border_radius':'20px',
    'input_border_width':'2px',
    'input_font':'Times New Roman, arial, fantasy',
    'input_font_weight':'400',
    'input_margin':'5px 0px 5px 0px',
    'input_padding':'0px 5px 0px 5px',
    'label_color':'#5D99CA',
    'label_size':'16px',
    'label_width':'150px',
    'label_font':'Times New Roman, sans-serif, serif',
    'label_font_weight':'light',
    'label_margin':'5px 0px 0px 0px',
    'label_padding':'0px 5px 0px 5px',
    'label_border_style':'solid',
    'label_border_color':'#EF9F6D',
    'label_border_radius':'20px',
    'label_border_width':'2px',
    'background_color':'white',
    'height':'25px',
    'width':'320px',
    'padding_bottom':'0px'
   },
   'exp': {
    'font_color':'#5D99CA',
    'border_color':'#EF9F6D',
    'border_style':'dashed',
    'font_size':'12pt',
    'input_border_radius':'0px',
    'input_border_width':'2px',
    'input_font':'arial, cursive, fantasy',
    'input_font_weight':'400',
    'input_margin':'5px 0px 5px 0px',
    'input_padding':'0px 5px 0px 5px',
    'label_color':'#5D99CA',
    'label_size':'16px',
    'label_width':'150px',
    'label_font':'arial, fantasy, serif',
    'label_font_weight':'normal',
    'label_margin':'5px 0px 0px 0px',
    'label_padding':'2px 5px 2px 5px',
    'label_border_style':'dashed',
    'label_border_color':'#EF9F6D',
    'label_border_radius':'0px',
    'label_border_width':'2px',
    'background_color':'white',
    'height':'25px',
    'width':'85px',
    'padding_bottom':'2px',
    'type':'dropdown'
   },
   'body': {
    'background_color':'white'
   }
  },
 authorization:
  {
   'clientKey': clientKey
  }
}).then(function(instance){
//use instance object to process and tokenize sensitive data payment fields.
});

Dynamic Styling Options

The following PTPayment methods can be used to style the Project.js Payment fields during runtime. To utilize these methods, you will need to implement them within the .then method once the promise has resolved.

Dynamic Styling Methods

Dynamic Styling Example

//PTPayment.getControl examples
PTPayment.getControl("securityCode").label.text("CSC");
PTPayment.getControl("creditCard").label.text("CC");
PTPayment.getControl("expiration").label.text("Exp Date");

//PTPayment.theme examples
PTPayment.theme('horizontal');
PTPayment.theme('above the line');
PTPayment.theme('below the line');
PTPayment.theme('label-none');
PTPayment.theme('label-extended-top');

//PTPayment.style examples
PTPayment.style({'cc': {'border_style': 'dashed'}});
PTPayment.style({'code': {'label_color': 'red'}});
PTPayment.style({'exp': {'type': 'textbox'}});