Skip to main content

3D Secure flow for API orders

Overview

3D Secure is a system designed to increase security of online transactions using cards by checking customer identities before allowing them to finalize purchase. 3D Secure works by redirecting your customers to pages provided by their banks, where they need to enter additional security tokens or password to trigger the completion of the charge.

By using 3D Secure, you get additional protection from liability for fraudulent card payments, with your customers having to go through an extra layer of authentication.

Introducing Dynamic 3D Secure via API

Starting with 2Checkout API 5.0, your orders placed via API are processed automatically through the Dynamic 3D Secure flow. Dynamic 3D Secure is mechanism that allows us to evaluate a transaction in real-time based on a range of rule parameters that are able to determine if 3D Secure should be enabled or not.

Based on specific filters set in our backend system, 3D Secure will be enabled or not on a transaction basis in real-time. The list of filters is includes:

  • Credit card issuing country
  • Billing country 
  • IP country 
  • Order amount

If one of these filters is not matching with the thresholds set in the 2Checkout system, 3D Secure will be enabled. Otherwise the transaction is considered to be safe and can go through without 3D Secure.

Availability

Placing orders via API with the 3D Secure flow is available starting with the version 5 of 2Checkout's API.

Benefits

Place orders via API starting with version 5, and let Dynamic 3D Secure mechanism bring you the following advantages:

  • Increased authorization rates – we measured and observed that in specific countries the use of 3D Secure could have an overwhelmingly positive impact (United Kingdom, Russia) while in other countries it has a negative impact (United States, China).
  • Mitigated fraud risks – 3D Secure significantly decreased the fraud rate for your incoming orders.
  • Less chargeback – the use of 3D Secure can reduce the number of chargebacks in some cases (e.g. reasons like fraud/not recognized) as customers are not allowed to open a chargeback with their bank.

How it works

For credit card orders placed starting with 2Checkout API 5.0, you need to pass through additional parameters that support the Dynamic 3D Secure flow.

Send the following parameters as part of the PaymentMethod object:

Parameters Description
Vendor3DSReturnURL Required (string)
  URL address to which customers are redirected after the 3DS details get validated by the bank and the order is successfully authorized.
Vendor3DSCancelURL Required (string)
  URL address to which customers are redirected if the 3DS details were not validated or the order could not be authorized.

 

Shipping in API

Overview

Use the API methods displayed below to create orders for physical products.

Search the shipping methods defined in your Control Panel, and extract information on how the shipping price is calculated.

 

Integrate Service Provider Pro (SPP)

Availability

Service Provider Pro (SPP) integration is available only for 2Checkout accounts that handle their own tax and invoice management (2Sell and 2Subscribe accounts). 

2Checkout Settings

To integrate with 2Checkout you’ll need to get your merchant code and secret word from 2Checkout.

  • Create a 2Checkout account.
  • Log into your 2Checkout account.
  • In your dashboard, navigate to Integrations → Webhooks & API
  • Your account number is at the top of the API section, under Merchant code
  • Your Secret Word is located in the Secret word section:
    • Generate a new INS Secret Word and paste it in the Secret word section on this page
    • Your INS secret word should be the same as the buy-link secret word (found under Dashboard → Integrations → Webhooks & API, scroll down to the Secret Word area, as shown in the image below). Edit your INS secret word and buy-link secret word to match each other, then copy and paste them into your SPP admin.INS secret word.png
    • Click on Save settings
  • Enter both the seller ID (Merchant code) and your secret word in the SPP module
  • On the settings page, navigate to Notification URL. Use this URL to set up notifications in your 2checkout account. (SPP can capture recurring subscription payment, canceled orders, and refunds or chargebacks.)
    • Go to 2checkout Dashboard → Integrations → Webhooks & API section
    • Check the Enable INS and the Enable global URL checkboxes
    • Paste the link from SPP in the field below the “Enable global URL”
    • Click Update to save your settings

About Service Provider Pro (SPP)

SPP is a boutique product-focused company that handles services businesses. Launched in 2014, SPP is helping professionals and agencies sell millions of dollars in services. Find out more about SPP here.

Key generators

Overview

For digital products like software and phone cards, product activation means sending the client an email message containing either a binary key (especially for software products) or an activation alphanumeric code. The key or the code is used for unlocking the subscriptions or getting access to website content.

This feature is implemented by storing the keys or codes using two different types of lists:

  • Static lists
  • Dynamic lists

Static lists

To create static lists:

  1. Navigate to Fulfillment under Setup.
  2. Enter a name and select the list type: Static.
  3. Choose the type of codes your customers receive:
    • A single activation code that is shared by all shoppers. 
    • Multiple codes that you can enter manually, one per line. You can also tweak the way that 2Checkout handles:
      • Duplicates. Your list may or may not contain duplicate codes. 
      • Codes in the context of a number of units purchased. Send multiple codes according to product quantity or a single code regardless of the number of units purchased. 
      • Notifications when a list is running low on available codes. 
  4. Assign the products for which 2Checkout delivers codes from the list. 

Dynamic lists

Use this option if you host the key generator on your servers.

Workflow

  1. 2Checkout queries your code generator.
  2. Your code generator creates the codes and provides them to 2Checkout.
  3. 2Checkout delivers the codes to your shoppers in fulfillment emails, on the Thank You Page, and in their myAccount. 

Code generator output

For each approved order, 2Checkout queries your server with certain parameters (see parameters table) that you can use to generate codes/binary keys. Depending on the code or key format (alphanumeric or binary) the 2Checkout system expects either a:

  • XML file (alphanumeric code or key)
  • Or a binary file response (binary code or key)

Limitations

Key generators hosted on websites with self-signed certificates are not allowed.

The Skip TLS validation rule set in System settings applies only for webhook notifications (IPN/LCN/INS) and does not work for key generators.

Add a Dynamic list 

To create dynamic lists:

  1. Navigate to Fulfillment under Setup.
  2. Enter a name and select the list type: Dynamic.
  3. Enter the URL corresponding to the location on your server where you host your key generator.
  4. Assign the products for which 2Checkout delivers codes from the list. 

Method and parameters

2Checkout sends the following parameters to your server using HTTP/HTTPS POST using the URL you supplied when configuring the dynamic list.

Field name

Description

PID

Unique, system-generated 2Checkout product ID.

PCODE

The product code you control. 

INFO

Additional information sent with the order.

REFNO

Order reference from the 2Checkout system. (maximum 9 characters)

REFNOEXT

Order reference from your own system, sent when the order has been generated

PSKU Product SKU

TESTORDER

Specifies if the order is for testing purposes. The only possible values are YES or NO.

QUANTITY

Ordered products quantity. (number of subscriptions for example)

FIRSTNAME

Shopper first name. (maximum 40 characters allowed)

LASTNAME

Shopper last name. (maximum 40 characters allowed)

COMPANY

Shopper company name 

ADDRESS Shopper's address.
STATE The shopper's state.
FAX Fax number.

EMAIL

Shopper email address. (maximum 40 characters allowed)

PHONE Shopper phone number.

LANG

ISO 639-1 two-letter code. The language used for transactions ("en" or "ro" for example)

COUNTRY

Shopper country. (maximum 50 characters allowed)

COUNTRY_CODE ISO code for the shopper country.

CITY

Shopper city. (maximum 30 characters allowed)

ZIPCODE

Shopper zip code. (max 20 characters allowed)

LICENSE_TYPE

Sent for subscriptions. Possible values:

  • REGULAR: for new subscriptions/licenses 
  • TRIAL: for paid trial subscriptions/licenses
  • RENEWAL: for renewed subscriptions/licenses
  • UPGRADE: for upgraded subscriptions/licenses

LICENSE_REF

Unique, system-generated subscription reference number in the 2Checkout system. Maximum 10 characters.

LICENSE_EXP

Subscription expiration date in the format: 2003-12-25 02:30:45

When the product has been purchased with the "one-time fee" (lifetime) options enabled, the value is: 9999-12-31 23:59:59

The LICENSE_EXP DateTime stamp takes into account the custom time zone you selected via system settings under Account settings, or 2Checkout's default GMT+02:00

LICENSE_LIFETIME

This parameter indicates whether 2Checkout generated a lifetime subscription for the product.

  • 1 = lifetime subscription is on for the product 
  • 0 = lifetime subscription is off for the product
PARTNER_CODE

Possible values:

  • Empty = eCommerce order
  • Partner code

If sent, the partner code is also included when the HMAC is calculated.

TIMEZONE The time zone you selected or the default GMT+02:00 time zone of the 2Checkout system.
Parameters LICENSE_TYPE, LICENSE_REF, LICENSE_EXP and LICENSE_LIFETIME are not included in the debug. This is due to the fact that these parameters are not used for the HASH calculation. There is no subscription created by the debug so there are no related parameters to be sent to the key gen when the debug is made, as no code needs to be generated. This process is just querying the keygen to ensure that it is working by sending the HASH which the keygen should validate and return a 200 OK response if it matches.

If you configure additional order fields and 2Checkout collects this type of info during the checkout process, it will be included in the POST request:

Additional field names for orders

Field Name

Description

CUSTOM_FIELD_TEXT[]

Array with all the custom fields texts set per order.

CUSTOM_FIELD_VALUE[]

Array with all clients' input corresponding to the text.

 

Additional field names for products

Field Name

Description

CUSTOM_FIELD_714585_TEXT[]

Array with all the custom fields texts set per product.

CUSTOM_FIELD_714585_VALUE[]

Array with all clients' input corresponding to the text.

 

If you configure per-product price options 2Checkout also includes them in the POST request. Example: 2Checkout product ID (PID):714585

Field Name

Description

PRODUCT_OPTIONS_714585_TEXT[]

Array with all the price options texts set per product.

PRODUCT_OPTIONS_714585_VALUE[]

Array with all clients input corresponding to the text.

PRODUCT_OPTIONS_714585_PRICE[]

Array with all the prices corresponding for each option (prices are in the order currency)

PRODUCT_OPTIONS_714585_OPERATOR[]

Array with all the prices operators (ADD, SUBTRACT) corresponding for each price option

Generating the output

You can package your response as:

  • XML for alphanumerical codes (Basic XML or Advanced XML)
  • Binary attachment for binary keys
  • Error code sent in the HTTP headers

XML files have certain reserved characters that must be escaped in a certain way when used. The reserved characters and their corresponding escape sequences are: 

  • & (ampersand) converted to & 
  • < (less than) converted to &lt; 
  • > (greater than) converted to &gt; 
  • " (double quote) converted to " 
  • ' (single quote) converted to ' 

When XML files are created, please replace these characters in the attributes and inside the nodes with the correct escape sequence to have a syntactically correct XML document. These characters are documented in the XML specification: http://www.w3.org/TR/REC-xml/

HTTP Headers

HTTP servers use a large number of response and status codes, usually transparent for the navigator. These codes tell the browser if there was an error or not. The codes are embedded in the HTTP header of the client/server communication. The success status code is 200 while any other code is an error. For example, 400 means "Bad Request" and 403 means "Forbidden". HTTP response header examples:

  • HTTP/1.0 400 Bad Request
  • HTTP/1.0 200 OK

Content-type

Set the value of the Content-Type field to text/xml" in the header response when you package your response as XML.

Content-Type: text/xml

For all other values, 2Checkout s the content is a binary key.

Basic XML Answer format sample

Use the following template for your XML file :

<?xml version="1.0" encoding="UTF-8"?> 
<Data>
<code>SIMPLE_CODE 1</code>
<code>SIMPLE_CODE 2</code>
...
<code>SIMPLE_CODE N</code>
</Data>
XML tag Description
<code> The code you deliver for the product. Include each standalone code between <code></code> tags.
<description> Optional. A global description per delivery/fulfillment.

Binary Attachment format

If you deliver a binary file, instead of XML, set the value of Content-Disposition in the header as in the example below. Include the attached file containing the key in the body of the message. Set the filename using the 'Content-Disposition' field.

Content-Disposition: attachment; filename=key.bin

Advanced XML Answer format

If you need to attach additional installation instructions or details to the delivered codes, you can use the XML structure detailed below:

<?xml version="1.0" encoding = "UTF-8" ?>
<data>
<description>General description (for all codes below)</description>
<code>
<description>Description for CODE 1 and/or the binary.key</description>
<key>CODE1</key>
<file name="binary.key" content_type = "text/plain">
UklGRhTsCABBVkkgTElTVCQBAABoZHJsYXZpaDgAAABqBAEAgPQDAAAAAAAQAAEALQAAAAAA
AAACAAAAgD4AAEABAADwAAAAAAAAAAAAAAAAAAAAAAAAAExJU1R0AAAAc3RybHN0cmD4MQAA
</file>
</code>
<code>
<description>Description for CODE 2</description>
<key>CODE 2</key>
</code>
<code>
<description>Description for the the binary_2.key</description>
<file name = "binary_2.key" >
UklGRhTsCABBVkkgTElTVCQBAABoZHJsYXZpaDgAAABqBAEAgPQDAAAAAAAQAAEALQAAAAAA
AAACAAAAgD4AAEABAADwAAAAAAAAAAAAAAAAAAAAAAAAAExJU1R0AAAAc3RybHN0cmD4MQAA
</file>
</code>
</data>
XML tag Description
<key> The key you deliver for the product. Include each standalone code between <key></key> tags.
<description>

If it is contained in the <data></data>node, then it is treated as a global description per delivery/fulfillment.

If it is embedded in the <code></code> node, then it is a description for that code.

<file> Optional field. A base64-encoded file.
<code>

A <code> tag answer must contain at least one of the elements <key>or <file>.

Security 

For security reasons we strongly recommend that you limit access to the key generator URL used to generate access codes or keys and grant access only to the 2Checkout server IP networks. 

HASH field

Use the value of the HASH field to check data integrity. 

Field Name

Description

HASH

HASH signature SHA-2/SHA-3 HMAC created using all the fields sent through HTTP/HTTPS POST.

Calculate the HASH signature

Example using the following data:

Field name

Length

Field value

PID

6

189645

PCODE

3

123

REFNO

7

1250747

REFNOEXT

0

 

TESTORDER

3

YES

QUANTITY

1

1

FIRSTNAME

4

John

LASTNAME 3 Doe

COMPANY

0  
EMAIL 18 info@2checkout.com
LANG 2 en
COUNTRY 11 Netherlands

COUNTRY_CODE

2 nl
CITY 10

Amstelveen

ZIPCODE

4

1181

 

Source string for HMAC_SHA is calculated by pre-pending each field value with its own length. The source string for the data above is:
618964531237125074703YES114John3Doe018info@2checkout.com2en11Netherlands2nl10Amstelveen41181
Secret key for this example SECRETKEY
HASH value SHA-2 a141c737f23ccbe0e2bc88a1c81532a6
HASH value SHA-3  

Don't forget to check if the received order reference matches a valid reference order from your system.

Test orders

In the case of test orders, 2Checkout populates the TESTORDER parameter with the value YES. It is highly recommended to reply with testing codes or keys whenever receiving the above-mentioned parameter in the server request, and not codes/keys you would send to actual shoppers.

Code sample

<?php
/* Electronic Delivery */

/* pass to compute HASH. Retrieve your secret key by accessing https://secure.2checkout.com/cpanel/webhooks_api.php */
$secretKey = "AABBCCDDEEFF";

$signature = $_POST['HASH']; // HASH received

function serializeArray($array) {
    $retval = "";
    foreach ($array as $i => $value) {
        if (is_array($value)) {
            $retval .= serializeArray($value);
        }
        else {
            $size = strlen($value);
            $retval .= $size . $value;
        }
    }
    return $retval;
}

unset($_POST['HASH']);

// calculate the hash for the fields received (excluding the hash) to make sure the post is from 2Checkout and wasn't altered on the way
$sha256Hash = hash_hmac('sha256', serializeArray($_POST), $secretKey);
// only for php version > 7.1
$sha3256Hash = '';
if (in_array('sha3-256', hash_algos())) {
    $sha3256Hash = hash_hmac('sha3-256', serializeArray($_POST), $secretKey);
}

// only for php version > 7.1; remove $sha3256Hash from the array otherwise
if (!in_array($signature, array_filter([$sha256Hash, $sha3256Hash]))) {
    http_response_code(400);
    mail("your_address@example.com","BAD ElDel Signature", print_r($_POST, TRUE),"");
    echo 'Invalid signature.'; // 2Checkout logs your answer for debug purposes

    return;
}


// if valid hash continue script

// rudimentary example of business logic
// this example uses only 2Checkout ProductId to decide the output

switch($_POST['PID']) {
    case '123': //for this product your key is a binary file
            
        header('HTTP/1.0 200 OK',false, 200); //inform 2Checkout you received a valid post, you shouldn't have to set this header explicitly
        header('Content-Type: application/octet-stream'); //set the mime type
        header('Content-Disposition: filename=key_123.bin'); //set the file name
        readfile(dirname(__FILE__).'/key_123.zip'); //output the file

        //make sure your script doesn't output anything after this point and/or stop script execution
        exit;

    case '1234': //for this product your key is a text file
            
        header('HTTP/1.0 200 OK',false, 200); //inform 2Checkout you received a valid post, you shouldn't have to set this header explicitly
        header('Content-Type: text/plain'); //set the mime type
        header('Content-Disposition: filename=key_1234.txt'); //set the file name
        readfile(dirname(__FILE__).'/key_1234.log'); //output the file

        //make sure your script doesn't output anything after this point and/or stop script execution
        exit;
            
    case '12345': //for this product your key is a string

        //build a basic xml with the following structure:
        $basic_xml =  '<?xml version="1.0"?>
                            <data>
                                <code>12345 key</code> <!-- your string key here -->
                            </data>';
            
        header('HTTP/1.0 200 OK',false, 200); //inform 2Checkout you received a valid post, you shouldn't have to set this header explicitly
        header('Content-Type: text/xml');
        echo  $basic_xml; //make sure the script doesn't output anything after this point and/or stop script execution
        exit;

    case '123456': //this product is a bundle and contains several string keys
            
        //the xml gets a bit more complicated
        $advanced_xml ='<?xml version="1.0"?>
                            <data>
                              <description>Bundle 123456</description> <!--General description (for all codes below), it will be displayed/sent to enduser-->
                              <code>
                                  <description>key for bundle component 1</description> <!--description for CODE 1, it will be displayed/sent to enduser -->
                                  <key>bundle comp 1 </key> <!-- string key -->
                              </code>
                              <code>
                                  <description>key for bundle component 2</description> <!--description for CODE 2, it will be displayed/sent to enduser -->
                                  <key>bundle comp 2 </key> <!-- string key -->
                              </code>
                            </data>';
            
        header('HTTP/1.0 200 OK',false, 200); //inform 2Checkout you received a valid post, you shouldn't have to set this header explicitly
        header('Content-Type: text/xml');
        echo  $advanced_xml; //make sure the script doesn't output anything after this point and/or stop script execution
        exit;

    case '1234567': //this product is a bundle and one of the products has a string file and a file attached
            
        //the xml contains the new tags: file and extra
        $advanced_xml ='<?xml version="1.0"?>
                            <data>
                              <description>Bundle 123456</description> <!--General description (for all codes below), it will be displayed/sent to enduser-->
                              <code>
                                  <description>key for bundle component 1</description><!-- description for CODE 1, it will be displayed/sent to enduser -->
                                  <key>bundle comp 1 </key><!-- string key -->
                                   <file name="binary.key" content_type = "text/plain"><!-- the file name and content type will be used when offering the file for download to user.
                                   <![CDATA['.base64_encode(file_get_contents(dirname(__FILE__).'/key_p1_1234567.log')).']]>
                                   </file>
                              </code>
                              <code>
                                  <description>key for bundle component 2</description> <!--description for CODE 2, it will be displayed/sent to enduser -->
                                  <key>bundle comp 2 </key> <!-- string key -->
                                  <extra type="INSTALL_HOTLINE" label="Install hotline number">0740216669</extra> <!--the content and label of the extra tags is displayed in cpanel and sent to end-user through the electronic delivery mail-->
                                  <extra type="OPERATING_SYSTEM" label="Works on the following operating systems">Windows XP, Windows 7, Windows 8</extra> <!--the content and label of the extra tags is displayed in cpanel and sent to end-user through the electronic delivery mail-->
                              </code>
                            </data>';
            
        header('HTTP/1.0 200 OK',false, 200); //inform 2Checkout you received a valid post, you shouldn't have to set this header explicitly
        header('Content-Type: text/xml');
        echo  $advanced_xml; //make sure the script doesn't output anything after this point and/or stop script execution
        exit;
}

Quick payment reports

Overview

Quick payments allow you to provide extra money to your top affiliates either though a one-time payment or via recurrent payments.

Availability

All 2Checkout accounts. 

Generate quick payments reports

You can find the Quick payments tab in the Accounting -> Direct payments menu.

  1. Use the Quick payments search section to configure the filters used in generating the report. You can filter the results by target affiliate, website or the payment date.
  2. Once you have finished configuring your filters, click Search. The report is displayed below and it contains 10 results/page. You can extend the displayed results number to 20 results/page
  3. To export the entire report as a CSV file you can use the Export as CSV button.

The report shows you the payment date, the target affiliate, the amount you paid to your affiliate, 2Checkout's commission and the payment status (Succeeded orFailed).

Subscription Management

Overview

Manage the lifecycle of your subscriptions and control different processes such as delaying the start of a subscription, canceling a subscription, searching a subscription from the Subscriptions page in your Merchant Control Panel.

Availability 

The Subscriptions section is available to all 2Checkout accounts. For more details about subscriptions, read here.

 

Cross-sell

Overview

Use this object to retrieve information about the cross-sell campaigns you configured for your account. 

Parameters

Parameter Type/Description

MasterProducts

Array

 

Array of product codes for the items you set to trigger the cross-sell campaign.

DisplayType

String

 

  • cart – Shopping cart
  • review – Review page
  • finish – Thank you page

DisplayInEmail

Boolean

 

True or false depending on whether you set the cross-sell campaign to display in payment receipt emails or not.

Products

Array of objects

 

Details below

 

ProductCode

String

 

 

Product code for the item you set as recommended for the cross-sell campaign.

 

Discount

String

 

 

Value of the discount. This is a percentage.

 

DiscountType

String

    PERCENT – you can only set discounts as a percentage from the product price.
  Type String

 

 

Example: Own

  AutoAdded Boolean
  DiscountedPrice Array of objects
    Details below.
                            Currency String
                            Price Float
  BasePrice Array of objects
                            Currency String
                            Price Float

CampaignCode

String

 

Unique, system-generated cross-sell campaign code.

Name

String

 

Campaign name.

StartDate

String

 

YYYY-MM-DD. The start date you set for the cross-sell campaign.

EndDate

String

 

YYYY-MM-DD. The end date you set for the cross-sell campaign.

CampaignStatus String
  The status of the cross-sell campaign.
CampaignOwnerType String
  Campaign owner type: Can be either MERCH or AFF.

Convert a trial

Overview

Use the convertTrial method to convert a trial to a paid subscription. In the eventuality of a conversion failure, you can use convertTrial again for the same trial subscription only after you let 24 hours pass since the initial attempt. The 2Checkout system attempts to automatically convert trials before they expire to full subscriptions, unless you made an attempt that failed less than 24 hours before the scheduled expiration deadline.

In case the trial conversion fails due to a transaction issue, the 2Checkout system sends unfinished payment follow-up emails to customers, provided that you set up lead management for your account.

Parameters

Parameters Type/Description

SubscriptionReference

Required (string)

 

Unique, system-generated subscription identifier of the trial that you convert to a paid subscription. The unique identifier from the 2Checkout system:

  • Must belong to an active trial subscription with the recurring billing system (auto-renewal) enabled.
  • The initial order placed to access the trial subscription must be finalized (status Finished).

Note: This method does not work for cancelled and/or expired trial subscriptions.

 

2Checkout charges customers using the payment data attached to the trial subscription. In the case of credit/debit cards, if customers update their payment information in myAccount or if you update these details on behalf of your subscribers, the 2Checkout system uses the latest card info provided to charge subscription renewals.

ExtendSubscriptionFromPaymentDate

Optional (boolean)

 

true = Set the moment of the conversion as the start date of the full subscription. 

Example: A 7 day trial purchased on October 29 for a monthly subscription converted on October 30 with $ExtendSubscriptionFromPaymentDate = true; features the following Billing cycle expiration: Nov 30, 2013 and 2Checkout scraps the initial trial expiration date November 5.

 

false = Set initial trial expiration deadline as the fhe full subscription start date. 

Example: A 10 day trial purchased on October 29 for a monthly subscription converted on October 30 with $ExtendSubscriptionFromPaymentDate = false; features the following Billing cycle expiration: December 9, with the first month period of the subscription added to the trial lifetime stretching until November 8.

 

Can be NULL. If not sent, the default value is false.

Response

Parameters Type/Description

Boolean

true or false depending on whether the changes were successful or not.

Request


<?php

require ('PATH_TO_AUTH'); 
 
$SubscriptionReference = 'BF44555C6C';

$ExtendSubscriptionFromPaymentDate = true; //false can also be used if you want the subscription start date to be the moment when the trial was set to initially expire.

try {
    $convertedTrial = $client->convertTrial($sessionID, $SubscriptionReference, $ExtendSubscriptionFromPaymentDate);
}
catch (SoapFault $e) {
    echo "convertedTrial: " . $e->getMessage();
    exit;
}
var_dump("convertedTrial", $convertedTrial);

Search leads

Overview

Use the searchLeads method to retrieve leads created in the 2Checkout system.

Request Parameters

Parameters Required Type/Description
Page Required String. The page in the result set.
Limit Required Number. The number of items to be retrieved on each page.

Request Example

<?php

require ('PATH_TO_AUTH');

$LeadSearchInput = new stdClass();

$LeadSearchInput->Type = "New";
$LeadSearchInput->Language = "BG";
$LeadSearchInput->Country = "RO";
$LeadSearchInput->Page = 1;
$LeadSearchInput->Limit = 200;

try {
    $leadData = $client->searchLeads($sessionID, $LeadSearchInput);
} catch (SoapFault $e) {
    echo "searchLeads: " . $e->getMessage();
    exit;
}

var_dump("searchLeads", $leadData);

Response Example

class stdClass#4 (2) {
  public $Items =>
  class stdClass#5 (1) {
    public $0 =>
    class stdClass#6 (14) {
      public $LeadCode =>
      string(10) "60E6C4B574"
      public $GeneratedFrom =>
      string(3) "API"
      public $CartId =>
      string(11) "CartIdValue"
      public $Currency =>
      string(3) "EUR"
      public $Language =>
      string(2) "BG"
      public $ExternalReference =>
      string(18) "REST_API_3CHECKOUT"
      public $MachineId =>
      string(6) "123asd"
      public $LocalTime =>
      string(19) "2019-11-05 16:48:28"
      public $Items =>
      class stdClass#7 (1) {
        public $0 =>
        class stdClass#8 (15) {
          public $Code =>
          string(10) "04C26C50F8"
          public $Quantity =>
          string(1) "2"
          public $SKU =>
          NULL
          public $Name =>
          string(5) "softy"
          public $Description =>
          NULL
          public $IsDynamic =>
          bool(false)
          public $Tangible =>
          bool(false)
          public $PurchaseType =>
          string(7) "PRODUCT"
          public $PriceOptions =>
          NULL
          }
          public $RecurringOptions =>
          class stdClass#9 (5) {
            public $CycleLength =>
            NULL
            public $CycleUnit =>
            NULL
            public $CycleAmount =>
            NULL
            public $ContractLength =>
            NULL
            public $ContractUnit =>
            NULL
          }
          public $RenewalInformation =>
          class stdClass#10 (1) {
            public $SubscriptionReference =>
            NULL
          }
          public $MarketingCampaigns =>
          class stdClass#11 (3) {
            public $Type =>
            string(2) "23"
            public $ParentCode =>
            string(1) "m"
            public $CampaignCode =>
            string(2) "23"
          }
          public $Price =>
          class stdClass#12 (2) {
            public $Amount =>
            string(2) "20"
            public $Type =>
            string(6) "CUSTOM"
          }
          public $AdditionalFields =>
          NULL
          public $SubscriptionStartDate =>
          string(19) "2019-11-05 16:48:28"
        }
      }
      public $BillingDetails =>
      class stdClass#13 (12) {
        public $FirstName =>
        string(8) "Customer"
        public $LastName =>
        string(9) "2Checkout"
        public $Phone =>
        NULL
        public $Company =>
        NULL
        public $FiscalCode =>
        string(8) "32423423"
        public $Email =>
        string(22) "customer@2checkout.com"
        public $Address1 =>
        string(12) "Test Address"
        public $Address2 =>
        NULL
        public $City =>
        string(2) "LA"
        public $Zip =>
        string(5) "12345"
        public $CountryCode =>
        string(2) "RO"
        public $State =>
        string(2) "CA"
      }
      public $DeliveryDetails =>
      class stdClass#14 (12) {
        public $FirstName =>
        string(8) "Customer"
        public $LastName =>
        string(9) "2Checkout"
        public $Phone =>
        NULL
        public $Company =>
        NULL
        public $FiscalCode =>
        string(8) "32423423"
        public $Email =>
        string(22) "customer@2checkout.com"
        public $Address1 =>
        string(12) "Test Address"
        public $Address2 =>
        NULL
        public $City =>
        string(2) "LA"
        public $Zip =>
        string(5) "12345"
        public $CountryCode =>
        string(2) "RO"
        public $State =>
        string(2) "CA"
      }
      public $DeliveryInformation =>
      class stdClass#15 (1) {
        public $ShippingMethod =>
        class stdClass#16 (1) {
          public $Code =>
          string(5) "sdfsd"
        }
      }
      public $PaymentDetails =>
      class stdClass#17 (4) {
        public $Type =>
        string(2) "CC"
        public $Currency =>
        string(3) "EUR"
        public $PaymentMethod =>
        class stdClass#18 (2) {
          public $RecurringEnabled =>
          bool(false)
          public $CardPayment =>
          class stdClass#19 (1) {
            public $InstallmentsNumber =>
            string(2) "23"
          }
        }
        public $CustomerIP =>
        string(7) "1.2.3.4"
      }
      public $Promotions =>
      array(1) {
        [0] =>
        string(0) ""
      }
    }
  }
  public $Pagination =>
  class stdClass#20 (3) {
    public $Page =>
    int(1)
    public $Limit =>
    int(200)
    public $Count =>
    int(1)
  }
}

Customer

Overview

The object below is returned directly or within a successful response from the following API requests:

Retrieve a customer

Customer object

Parameters Type/Description

AvangateCustomerReference

Int

 

System-generated 2Checkout customer reference.

 

null when you create a new customer. The 2Checkout system generates default customer numerical (integer) IDs (AV_CUSTOMERID) automatically for all orders containing products that feature subscriptions.

 

 

Aggregate subscriptions under the same Customer account by adding the AV_CUSTOMERID (case sensitive) parameter to Buy links.

ExternalCustomerReference

String

 

Unique customer alphanumeric (string) identifiers you control. Aggregate subscriptions under the same Customer account by adding the CUSTOMERID (case sensitive) parameter to Buy links.

FirstName

String

 

Customer's first name. 

LastName

String

 

Customer's last name.

Company

String

 

Company name.

FiscalCode

String

 

Can be null for end users. For companies, it needs to be the VAT ID, which 2Checkout validates.

2Checkout throws an error if the VAT ID is invalid/incorrect. When present, you also need to provide the company name.

 

Can be null for end users.

Address1

String

 

Customer's address.

Address2

String

 

Customer's address.

City

String

 

Customer's city.

State

String

 

Customer's state. For example, "Alabama","Alaska","Arizona".

Zip

String

 

Zip code.

CountryCode

String

 

Customer's country code (ISO 3166 two-letter code).

Phone

String

 

Customer's phone number.

Fax

String

 

Customer's fax number.

Email

String

 

Customer's email.

Enabled

Boolean

 

true or false, depending on whether the customer account is active or inactive. An active customer account features at least one Active or Past due subscription. Possible customer statuses:

 

  • Active - Customer account status is Active even if Trial and Cancelled/Expired subscriptions exist for the customer, along as there's at least one Active subscription. Customers with a single subscription featuring the Past due status (expired but in the grace period) are considered Active.
  • Inactive - All subscriptions associated to this Customer account are cancelled, expired or both.
  • Trial - Customer account status is Trial if all Active subscriptions for this customer are trials, regardless of any Cancelled/Expired subscriptions.

Trial

Boolean

 

true or false, depending on whether the customer account features only trials or also paid subscriptions.

Language

String

 

ISO 639-1 two-letter code. Example: “en.”

Need help?

Do you have a question? If you didn’t find the answer you are looking for in our documentation, you can contact our Support teams for more information. If you have a technical issue or question, please contact us. We are happy to help.

Not yet a Verifone customer?

We’ll help you choose the right payment solution for your business, wherever you want to sell, in-person or online. Our team of experts will happily discuss your needs.

Verifone logo