The Acceptiva API

Important Notes

• The API response output can be in your preferred method: JSON, PHP, or XML.  
• Although there is a robust security model in place to keep all information secure, we request that you use the test credit card and bank account data provided and not real credit card or bank account information.
• For more detailed documentation of request parameters, development error codes, transaction error codes, and object structure documentation, go to: https://sandbox.acceptivapro.com/api/api_request.php?api_key=INSERT_API_KEY
• The example API calls in this document are shown as GET requests (with parameters in the query string) for illustration purposes only to make the examples more human-readable. When implementing your calls to the API they should always be made via POST.
• While testing, use the Sandbox domain  https://sandbox.acceptivapro.com/api/api_request.php?api_key=INSERT_API_KEY and the test values included in this document.
• Summary of differences between Sandbox and Live environments:

Sandbox	Live
Settlement of transactions (such as for testing refund functionality) is not automatic since there is no real transfer of funds taking place.	Settlement of transactions is automated at 11am PST next business day.
Ongoing recurring charges must be manually processed.	Ongoing recurring charges are automatically processed.
Error conditions can be forced for testing purposes.	Error conditions cannot be forced.

• Credit card transactions via the API will process with a minimum of:
  Account Name
  Card Number*
  Expiration Date*
  Dollar Amount (at least one item must be in the cart to calculate the total transaction amount)*
  Optional Fields are:
  Name on Card
  Billing Address*
  City
  State
  Country
  Zip Code*
  CVV Code*
• NOTE: Merchant Account processing fees are quoted assuming that all of the bolded* fields above are sent with the transaction; even though 3 of the 6 are optional. The processing rate for a transaction may increase when less card data is sent.
• In the case that you do not implement your own duplicate prevention/checking on your end, it is suggested that the client_trans_id is used, as it safeguards against duplicate transaction processing.  Realize that it is technically simpler for you to implement duplicate checking on your end, because pre-generating a client_trans_id usually means you must store transactions in your own database so that the database can generate the unique ID.

Back to top

Valid Inputs

For a complete list of request parameters for all API actions, including character limits and required data input type, please visit: https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>

API Response

Back to top

After submitting a transaction request, the API will provide a response in JSON, XML, or a serialized PHP array that is user-selectable per request.  Reponse parameters are:

The “status” returned in the API charge and void response will show “success” or “failure,” and is an indication of whether the “trans_status” is in a success or failure state.  All trans_status codes and messages are included below for ease of interpretation.

Testing

Merchant IDs:

Test Credit Card Numbers:

Test Bank Account Numbers:

Transaction Error Codes:

To force any of the transaction errors, enter the code of the desired failed status into Sub ID 2 before submitting the request. For instance, passing Sub ID 2 = 6 will simulate a processor timeout error.

Special Inputs for Testing:

Functionality:

Campaigns

Campaigns are a tool that allow you to group transactions together that otherwise would have been standalone. This allows users to create reports based on campaign and to receive recurring summary emails for API transactions per campaign.

To assign a campaign, use the item-level parameter campaign_id_str. The value used for the campaign_id_str must already exist in our system as a campaign.  Clients must contact Acceptiva Customer Service to create campaigns, after which, the campaign_id_str can be found in the Acceptiva Client Manager. 

...&params[0][items][0][campaign_id_str]=X...

Extra Parameters

You can create your own extra parameters to collect additional data by using extra_params.  The name you give your extra parameter must contain only A-Z letters (case insensitive), 0-9 integers, underscores, and must be 64 characters or less. To create extra parameters, use the following format in your URL call:

&params[0][extra_params][my_extra_name]=my_value&params[0][extra_params][my_other_extra]=my_other_value

The example above would create two extra parameters for the transaction called “my_extra_name” and “my_other_extra” with values of “my_value” and “my_other_value” respectively.

Client_Trans_ID

You can assign your own client_trans_id for the transaction. Each client_trans_id is unique, meaning once you have used this ID, you will never be able to use it again for any other transaction. In the case that you do not implement your own duplicate prevention/checking on your end, it is suggested that a client_trans_id is set for each transaction, as this safeguards against duplicate transaction processing.  When the client_trans_id is used, duplicate transactions will be rejected and not displayed in the transaction list in the Client Manager.

Recurring and Pledge Transactions

For recurring transactions, the request must specify recurring frequency, recurring end criteria, and a recurring end value.  A start date for the recurring payments other than the date of the initial payment can be specified using the “recur_first_charge_date” parameter. Entering a value for the “amt_today” parameter allows the initial payment to be a different amount from the calculated recurring installment amount. To process recurring transactions in the sandbox environment, use https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action=process_recur&params[0][date]=<INSERT_DATE>. The date specified is the date for which you want to process recurring payments.  It can be omitted to process recurring for today. The recurring charges will be processed automatically for live transactions.

Pledges are indicated by submitting “true” for the “is_pledge” parameter. To submit an amount to be paid immediately other than the calculated installation for a pledge, enter the desired amount as the value for the “amt_today” parameter.  Note that Ongoing (0) and End After Total Amount Paid (2) recurring criteria are not valid for pledges.  The table below provides a list of recurring and pledge parameters and the inputs accepted for each.  For further documentation, visit  https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=show_object_structure&params[0][object]=items_array. Refer to the Appendix for examples of recurring and pledge transaction URL strings.

Callback URL

Some actions have an optional callback URL parameter, which will be called when the action is complete. The response data will be POSTed to the callback URL in the same structure as the API output for that action. Callback URLs can be utilized for either synchronous or asynchronous transactions, although they are obviously most useful for asynchronous transactions where you can get a response on-demand from the API rather than having to poll periodically for the final response (which is highly discouraged).

 For testing purposes, to see what the callback response will look like, we provide the following url: https://sandbox.acceptivapro.com/api/api_request.php?email=youremail@domain.com. Using the url above as your test callback url will forward you an email with the response POST data formatted as human-readable.

Transaction Synchronicity

By default all API requests are handled synchronously. Some actions (such as 'charge') have support for asynchronous handling. A request to batch multiple transactions will always be handled asynchronously to avoid long delays and timeouts in receiving a response. In an asynchronous transaction, the API will give an initial response immediately after submission of the request without waiting for a bank response.  This initial response will indicate whether the submission was successful, but will not include the final transaction status.  To receive the report with the final status, a callback URL must be provided that will send the transaction details to your email.  As soon as a bank response is received and the status of the transaction is final, the transaction details will be sent to this URL, and thus to your e-mail. Do not periodically poll the API for a final transaction status. Note that batching more than 10 charge requests will force the entire batch to be performed asynchronously to avoid long processing delays.

To test asynchronous transactions, enter “1,” “yes,” or “true” into the “Async?” field.  Enter a URL into the “Callback URL” field that will send the transaction details to your email.  When you submit the request, the transaction details will be sent to the email specified by the URL.

Get_Trans_Details

To retrieve transaction details for a previous transaction, use the URL https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=get_trans_details&params[0][trans_id_str]=<INSERT_TRANS_ID_STR>&output=xml.  The trans_id_str is located in the API response report that opens after submitting the request, or in the e-mail sent to you if you completed an asynchronous transaction. Alternatively, an assigned client_trans_str can be used.

To get transaction details for multiple transactions at once, pass multiple trans_id_str or client_trans_id separated by a comma.  If the client_trans_ids are numerically serialized, a range can be passed to request a group of transaction detail reports.  For example: https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=get_trans_details&params[0][trans_id_str]=ID1,ID2,ID3&params[0][client_trans_id]=CLID1,CLID2,1-50&output=xml

With the get_trans_details action, details for all transactions associated with your API key will be retrieved if the trans_id_str parameter is left blank.  You can add a filter parameter to your request to limit the details retrieved to transactions that fulfill certain criteria. Documentation for available filters is available at https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=show_filters&params[0][object]=trans_filters_array&output=xml. 

The details for recurring transactions can be retrieved using the get_recur_details action.  The value passed for “trans_recur_id_str” can be a single value or a comma separated list.  The parameter can also be left blank to show all active recurring charges.  Submit: https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=get_recur_details&params[0][trans_recur_id_str]=<INSERT_TRANS_RECUR_ID_STR>&output=xml

  Note: Currently, the sandbox can be queried via 'GET' requests. However, when the API is in production only 'POST' requests will be supported.  This will ensure greater security of POST data and ensure that requests do not exceed the platform's URL length limits.

Saved Payers

Tokenization allows you to store and re-use payer information. Refer to the Appendix for examples of managing saved payers.  Stored parameters are:

To generate a saved payer token, use the action “store_payer_data.” The minimum parameters you must include are payer_fname, payer_lname, acct_name, and payment information for either credit card (cc_num, cc_exp_mo, and cc_exp_yr) or E-Check (ach_account_num and ach_routing_num). 

To save payer information while submitting a transaction request, set the parameter store_payer_data to Boolean true.  The API will generate a unique payer_id_str for each saved payer. You may also optionally specify your own client_payer_id for future use of the saved data.  Only the payment information pertaining to the payment type of the transaction will be saved, though additional payment information for other payment types can be added later.

To use saved payer information, set store_payer_data to Boolean false. Leave all payer parameters blank and submit the payer_id_str or client_payer_id.  Incoming payer data (name, address, city, state, zip, country, email, phone) will override the saved payer data and will be used for the transaction.

To update saved payer data, submit a valid payer_id_str and set store_payer_data to Boolean true.  Incoming payer data will be saved in place of the old data. To update payer information for a client_payer_id, you must submit the payer_id_str associated with that data.  This can be found using get_payer_details.

To fetch the details for saved payer data, use the URLs below:

Payer_id_str:  https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=get_payer_data&params[0][payer_id_str]=PAYER_ID_STR&output=xml

Client_payer_id: https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=get_payer_data&params[0][client_payer_id]=CLIENT_PAYER_ID&output=xml

Errors will be thrown in the following cases:

• When setting a new client_payer_id, a record already exists with the same client_payer_id
• The saved payer info can’t be found using client_payer_id or payer_id_str
• Both the client_payer_id and payer_id_str are used at once, but they each return different payer information
• The submitted client_payer_id or payer_id_str does not contain the payment information required for the type of payment being transacted.

Email Receipts

E-mail Receipts can be sent whenever a one time or recurring transaction takes place.  E-mail receipts are created and saved in the Client Manager, and are assigned an automatically generated receipt id.  There is no limit to the number of receipts that can be created, so there can be separate receipts saved for initial transactions and follow-on recurring transactions. 

The parameters receipt_id_str and recur_receipt_id_str differentiate between initial and follow-on recurring receipts, respectively.  To assign initial and recurring receipts, code the receipt id as the value for these parameters.  For example:

&params[0][receipt_id_str]=<ID_OF_INITIAL_RECEIPT>&params[0][recur_receipt_id_str]=<ID_OF_RECURRING_RECEIPT>

Additionally, in the case that a recurring transaction fails, a failed receipt can be sent.  Use the parameter recur_failed_receipt_id_str with a value of the desired receipt id as the value to set the failed receipt.

A default receipt can also be set, so that when the receipt_id_str,  recur_receipt_id_str, and recur_failed_receipt_id_str parameters are omitted from the code, the default receipt will automatically be sent. However, if the receipt parameters are passed, those values will always be used to override the default.  Therefore, if the parameters are included but are left blank, no receipt will be sent.

Voiding Transactions

Voiding charges is supported for credit card and e-check transactions.  Enter https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=void_trans&params[0][trans_id_str]=<INSERT TRANS_ID_STR>&output=xml into your browser. The transaction was successfully voided if the status is “success” and the trans_status is 13, displaying the message “Transaction voided.”  For e-check, the cut-off for voiding transactions is 11:00 am Pacific Standard Time, the day of the transaction.  The cutoff will not adjust with daylight savings.

Refunding Transactions

Refunding charges is supported for credit card and e-check transactions. In the URL examples below, either trans_id_str or client_trans_id can be used. Before the charge can be refunded, the transaction must be settled.  For the sandbox environment, settle transactions using: https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=settle_trans&params[0][trans_id_str]=<INSERT_TRANS_ID_STR>

URL for Full Refund: https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=refund_trans_full&params[0][trans_id_str]=<INSERT_TRANS_ID_STR>&output=xml

URL for Partial Refund: https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=refund_trans_partial&params[0][trans_id_str]=<INSERT_TRANS_ID_STR>&params[0][items][0][id_str]=<INSERT_ID_STR>&params[0][items][0][amt]=<INSERT_AMT>&output=xml.

Multiple partial refunds can be performed for a transaction until the full amount has been refunded. When a refund is successful, a refund_trans_id_str is generated. Alternatively, you may assign a client_refund_trans_id when passing your refund request that becomes the new client_trans_id. Use these ids to make calls to get_trans_details/void_trans/settle_trans/etc.

To cancel a pending refund, call void_trans (see Voiding Transactions) using the refund_trans_id or the new client_ trans_id.

Sub Clients

If you are using the API to process transactions for your own clients, you must separate transactions by client so funds are deposited to the correct merchant account and so that the billing process calculates fees for your clients’ transactions and any shared revenue separately.  In the Client Manager under the “Manage Sub Clients” link, all clients and sub clients are listed with their respective Client IDs.  To flag a transaction as belonging to a specific client, submit their Client ID as the value for Sub ID 1.  For Sub Clients, the parent client’s Client ID must be submitted as Sub ID 1 and the Sub Client’s ID as Sub ID 2. For instance:

...&params[0][sub_id1]=CLIENT_ID1&params[0][sub_id2]=CLIENT_ID2&...

Lightbox

The AcceptivaPro lightbox allows you to create a transaction flow where sensitive payment data never passes through your server. Payer information such as name, address, and cart data are entered on your front end form and posted directly to our secure lightbox, where payment card or E-check data is submitted. The look of the lightbox is completely customizable by uploading your own CSS and logo image from the client manager.

Basic code integration

<script id="accpro-js" type="text/javascript" src="https://pro.acceptiva.com/lightbox/main.js"></script><script text="text/javascript">var accpro_api_key = 'INSERT_API_KEY_HERE'; // REQUIRED</script>

For sandbox testing, use https://sandbox.acceptivapro.com/lightbox/main.js in place of the URLs in the examples given. This code should go immediately before the </body> tag, and assumes there are several elements present:

• A form with an id of “accpro-form.”
• A clickable object on the page with an id of “accpro-btn” which, when clicked, will open the lightbox to complete payment.
• A hidden form element with an id of “accpro-trans-id-str” which will contain the trans_id_str of the successful transaction to use for validation.

The form that the lightbox is attached to (accro-form by default) will get submitted automatically with the trans_id_str unless a custom callback function is utilized.

Customizable Parameters

Optional parameters are as follows.  Example values have been included to assist with formatting:

If the form, button, trans_id_str element, or any of the other optional parameters are utilized, the ACCPRO.init() needs to be called with those options specified, as in the example below. Also note that there is a placeholder for a logo on the lightbox with the id “logo.”  A logo and CSS file can be applied using the tools present in the Acceptiva Client Manager. You may wish to download our main.css file as a starting point for customization.

Example Lightbox Code

This is an example call to hook the lightbox to your page with all possible options:

<script id="accpro-js" type="text/javascript" src="https://pro.acceptiva.com/lightbox/main.js"></script>
<script text="text/javascript">

function testCallback(data)
{
    console.log(data.trans_id_str); // Print the returned trans_id_str to the browser's console. Instead you would usually want to submit this value to yourself (usually via hidden form input) to subsequently make the 'check_trans' API call with it.
}

var accpro_api_key = 'abc123'; // REQUIRED

var options =
{
        button_id: 'my-btn', // optional, default 'accpro-btn' or the first submit button on the page
        css_url: 'https://path/to/your.css', // optional, must be HTTPS
        default_payment_type: 2, // optional, default 1
        form_id: 'my-form', // optional, default 'accpro-form' or the first form on the page
        merch_acct_id_str: { 1: 'MY_CC_MERCH_ACCT_ID_STR', 2: 'MY_ECHECK_MERCH_ACCT_ID_STR' }, // optional, client account defaults will be used
        payment_types: 3, // optional, default 3
        show_address: false, // optional, default true
        show_cvv: false, // optional, default true
        success_callback: testCallback, // optional
        trans_id_str_id: 'my-trans-id-str' // optional, default 'accpro-trans-id-str'
};

ACCPRO.init(options);

</script>

IE9 Integration

If you want your lightbox to work with Internet Explorer 9, you will need to add some extra code.  At the very top of your payment form, add:

<!doctype html>
	

And in your <head> section, add:

<meta http-equiv="X-UA-Compatible" content="IE=Edge">
	

The AcceptivaPro lightbox is not compatible with versions of IE earlier than version 9.

Appendix

Example Test Transaction Strings

Below are sets of parameters for example transactions with the URL strings that must be submitted to process them.  You may use this as a template to generate your own test transactions.

Example Credit Card and E-check/ACH Transactions

1. Credit Card Transaction

Parameters:
api_key (use your api_key)
action: charge
payer_fname: Jane
payer_lname: Tester
payment_type: 1
merch_acct_id_str: 154 (omit to use default for your account/payment type)
acct_name: Jane Tester
cc_num: 4111111111111111
cc_exp_mo: 12
cc_exp_yr: 2016
dynamic_descriptor: Building Fund (omit to use default for your account)
client_trans_id: 12345 (must be unique each time, or omitted)
sub_id1: 112233
items:
   id: 00123
   desc: Widget
   amt: 12.34
   qty: 2

URL:

https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=charge&params[0][payer_fname]=Jane&params[0][payer_lname]=Tester&params[0][payer_zip]=99997-0008&params[0][payment_type]=1&params[0][merch_acct_id_str]=154&params[0][acct_name]=Jane%20Tester&params[0][cc_num]=4111111111111111&params[0][cc_exp_mo]=12&params[0][cc_exp_yr]=2016&params[0][dynamic_descriptor]=Building%20Fund&params[0][client_trans_id]=12345&params[0][sub_id1]=112233&params[0][items][0][id]=00123&params[0][items][0][desc]=Widget&params[0][items][0][amt]=12.34&params[0][items][0][qty]=2

2. E-Check/ACH Transaction

Parameters:
api_key: (use your api_key)
action: charge
payer_fname: Jane
payer_lname: Tester
payment_type: 2
merch_acct_id_str: 32 (omit to use default for your account/payment type)
acct_name: Jane Tester
ach_acct_num: 0012345
ach_routing_num: 123456780
client_trans_id: 12345 (must be unique each time, or omitted)
sub_id1: 112233
items:
   id: 00123
   desc: Widget
   amt: 12.34
   qty: 2

URL:

https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=charge&params[0][payer_fname]=Jane&params[0][payer_lname]=Tester&params[0][payment_type]=2&params[0][merch_acct_id_str]=32&params[0][acct_name]=Jane%20Tester&params[0][ach_acct_num]=0012345&params[0][ach_routing_num]=123456780&params[0][client_trans_id]=6789&params[0][sub_id1]=112233&params[0][items][0][id]=00123&params[0][items][0][desc]=Widget&params[0][items][0][amt]=12.34&params[0][items][0][qty]=2

Example Recurring Transactions

1. Ongoing:

recur_freq = 3 (monthly; the frequency doesn't affect how the other 2 parameters are used)
recur_end_criteria = 0
recur_end_value = N/A

URL:

https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=charge&params[0][payer_fname]=Jane&params[0][payer_lname]=Tester &params[0][payer_zip]=99997-0008&params[0][payment_type]=1&params[0][merch_acct_id_str]=154&params[0][acct_name]=Jane%20Tester&params[0][cc_num]=4111111111111111&params[0][cc_exp_mo]=12&params[0][cc_exp_yr]=2016&params[0][dynamic_descriptor]=Building%20Fund&params[0][sub_id1]=112233&params[0][items][0][id]=00123&params[0][items][0][desc]=Widget&params[0][items][0][amt]=12.34&params[0][items][0][recur_freq]=3&params[0][items][0][recur_end_criteria]=0

2. End after 3 payments:

recur_freq = 3
recur_end_criteria = 1
recur_end_value = 3

URL:

https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=charge...<INSERT_OTHER_PARAMETERS>...&params[0][items][0][recur_freq]=3&params[0][items][0][recur_end_criteria]=1&params[0][items][0][recur_end_value]=3

3. End after $100 has been paid in total:

recur_freq = 3 
recur_end_criteria = 2
recur_end_value = 100

URL:

https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=charge...<INSERT_OTHER_PARAMETERS>...&params[0][items][0][recur_freq]=3&params[0][items][0][recur_end_criteria]=2&params[0][items][0][recur_end_value]=100

4. End by the end of the year: 

recur_freq = 3 
recur_end_criteria = 3
recur_end_value = 12/31/2019

URL:

https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=charge...<INSERT_OTHER_PARAMETERS>...&params[0][items][0][recur_freq]=3&params[0][items][0][recur_end_criteria]=3&params[0][items][0][recur_end_value]=12/31/2019 

Example Pledge Transactions

1. Pledge w/ 3 payments and $50 paid today (normal installments are calculated to be $25)

is_pledge = true
recur_freq = 3
recur_end_criteria = 1
recur_end_value = 3
amt_today = 50

URL:

https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=charge&params[0][payer_fname]=Jane&params[0][payer_lname]=Tester&params[0][payer_zip]=99997-0008&params[0][payment_type]=1&params[0][merch_acct_id_str]=154&params[0][acct_name]=Jane%20Tester&params[0][cc_num]=4111111111111111&params[0][cc_exp_mo]=12&params[0][cc_exp_yr]=2016&params[0][dynamic_descriptor]=Building%20Fund&params[0][sub_id1]=112233&params[0][items][0][id]=00123&params[0][items][0][desc]=Widget&params[0][items][0][amt]=100&params[0][items][0][is_pledge]=true&params[0][items][0][recur_freq]=3&params[0][items][0][recur_end_criteria]=1&params[0][items][0][recur_end_value]=3&params[0][items][0][amt_today]=50

2. Pledge ending in 2 months and $50 paid today (normal installments are calculated to be $25)

is_pledge = true
recur_freq = 3
recur_end_criteria = 3
recur_end_value = 12/31/2015
amt_today = 50

URL:

https://sandbox.acceptivapro.com/api/api_request.php?api_key=<INSERT_API_KEY>&action[0]=charge...<INSERT_OTHER_PARAMETERS>...&params[0][items][0][is_pledge]=true&params[0][items][0][recur_freq]=3&params[0][items][0][recur_end_criteria]=3&params[0][items][0][recur_end_value]=12/31/2015&params[0][items][0][amt_today]=50

Examples: Tokenization Use and Management

The examples below list the parameters to include in the transaction URL string.

Example 1 (using already stored CC data

payment_type = 1
payer_id_str = <valid payer_id_str for this API key that has CC data saved. Only payer_id_str OR client_payer_id needs to be passed, if both passed they must match the same payer>
client_payer_id = <valid client_payer_id for this API key that has CC data saved. Only payer_id_str OR client_payer_id needs to be passed, if both passed they must match the same payer>
payer_fname, payer_lname, acct_name, payer_address, payer_city, payer_state, payer_zip, payer_country, payer_phone, payer_email = <blank or omitted>
cc_num = <blank or omitted>
cc_exp_mo = <blank or omitted>
cc_exp_yr = <blank or omitted>
store_payer_data = false
Stored CC data will be used and nothing in the payer data will be updated

Example 2 (adding ACH data):

payment_type = 2
payer_id_str = <valid payer_id_str for this API key that has CC data saved. Only payer_id_str OR client_payer_id needs to be passed, if both passed they must match the same payer>
client_payer_id = <valid client_payer_id for this API key that has CC data saved. Only payer_id_str OR client_payer_id needs to be passed, if both passed they must match the same payer>
payer_fname, payer_lname, acct_name, payer_address, payer_city, payer_state, payer_zip, payer_country, payer_phone,
payer_email = <blank or omitted>
ach_acct_num = <whatever>
ach_routing_num = <valid routing num>
store_payer_data = true
ACH data will now be stored for this payer as well and client_payer_id will be updated if passed in and is unique

Example 3 (updating CC data and address)

payment_type = 1
payer_id_str = <valid payer_id_str for this API key that has CC data saved. Only payer_id_str OR client_payer_id needs to be passed, if both passed they must match the same payer>

client_payer_id = <valid client_payer_id for this API key that has CC data saved. Only payer_id_str OR client_payer_id needs to be passed, if both passed they must match the same payer>
payer_address = <new address>
payer_city = <new city>
payer_state = <new state>
payer_zip = <new zip>
payer_country = <new country>
payer_phone = <new phone>
payer_email = <new email>

cc_num = <new cc num>
cc_exp_mo = <new cc exp mo>
cc_exp_yr = <new cc exp yr>

ach_acct_num = IGNORED even if present
ach_routing_num = IGNORED even if present
store_payer_data = true

Example 4 (updating ACH data and address)

payment_type = 2
payer_id_str = <valid payer_id_str for this API key that has CC data saved. Only payer_id_str OR client_payer_id needs to be passed, if both passed they must match the same payer>
client_payer_id = <valid client_payer_id for this API key that has CC data saved. Only payer_id_str OR client_payer_id needs to be passed, if both passed they must match the same payer>
payer_address = <new address>
payer_city = <new city>
payer_state = <new state>
payer_zip = <new zip>
payer_country = <new country>
payer_phone = <new phone>
payer_email = <new email>
ach_acct_num = <new ach acct num>
ach_routing_num = <new ach routing num>
cc_num = IGNORED even if present
cc_exp_mo = IGNORED even if present
cc_exp_yr = IGNORED even if present
store_payer_data = true