Skip to main content

Update partner user

Overview

Use the updatePartnerUser method via SOAP API 6.0 to update a partner user. 

Required parameters

Parameter  Type Required/Optional Description
sessionID String Required Output of the Login method.
UUID String Required Partner unique identifier.
partnerUserUUID String Required Partner user unique identifier.

Request sample

<?php

declare(strict_types=1);

class Configuration
{
    public const MERCHANT_CODE = '';
    public const MERCHANT_KEY = '';
    public const URL = 'http://api.2checkout.com/soap/6.0';
    public const ACTION = 'updatePartnerUser';
    public const ADDITIONAL_OPTIONS = null;
    public const PARTNER_UUID = '95b6b8bd-20db-478a-9682-d165f5d85d46';
    public const PARTNER_USER_UUID = '95c329d6-b45d-44ea-856a-1af254d06ae9';

    //array or JSON
    public const PAYLOAD = <<<JSON
{  
    "Email": "test@test.com",
    "FirstName": "test", 
    "LastName": "test",  
    "Position": "test",  
    "PhoneNumber": "98765432123", 
    "MobilePhone": "8179186432",
    "Status": "ACTIVE" 
}
JSON;
}

class Client
{
    public function call(
        string $url = Configuration::URL,
        $payload = Configuration::PAYLOAD,
        string $action = Configuration::ACTION
    ): ?object
    {
        if (is_array($payload)) {
            $payload = json_encode($payload);
        }
        if (!empty($payload)) {
            // SoapClient works with objects(StdClass)
            $payload = json_decode($payload);
        }

        $soapClient = $this->getClient($url);
        $sessionId = $this->getSession($soapClient);
        $args = array_filter([$sessionId, Configuration::PARTNER_UUID, Configuration::PARTNER_USER_UUID, $payload]);

        return $soapClient->$action(...$args);
    }

    public function getClient(string $url): SoapClient
    {
        return new SoapClient(
            $url . '?wsdl',
            [
                'location' => $url,
                'cache_wsdl' => WSDL_CACHE_NONE,
            ]
        );
    }

    public function getSession(SoapClient $client)
    {
        $date = gmdate('Y-m-d H:i:s');
        $merchantCode = Configuration::MERCHANT_CODE;
        $key = Configuration::MERCHANT_KEY;
        $string = strlen($merchantCode) . $merchantCode . strlen($date) . $date;
        $hash = hash_hmac('md5', $string, $key);
       // $client->__setCookie('XDEBUG_SESSION', 'PHPSTORM');
        return $client->login($merchantCode, $date, $hash);
    }
}

try {
    $client = new Client();
    var_dump($client->call());
} catch (Exception $ex) {
    var_dump($ex);
}

Response

{
    "UUID": "95d59280-3b7d-4d5b-8b9f-7b66fe900045",
    "Email": test@test.com,
    "FirstName": "test2",
    "LastName": "test2",
    "Position": "test2",
    "PhoneNumber": "98765432123",
    "MobilePhone": null,
    "Status": "ACTIVE"
}

 

Create partner user

Overview

Use the createPartnerUser method via SOAP API 6.0 to add a partner user. 

Required parameters

Parameter  Type Required/Optional Description
sessionID String Required Output of the Login method.
UUID String Required Partner unique identifier.

Request sample

<?php

declare(strict_types=1);

class Configuration
{
    public const MERCHANT_CODE = '';
    public const MERCHANT_KEY = '';
    public const URL = 'http://api.2checkout.com/soap/6.0';
    public const ACTION = 'createPartnerUser';
    public const ADDITIONAL_OPTIONS = null;
    public const PARTNER_UUID = '95b6b8bd-20db-478a-9682-d165f5d85d46';
    //array or JSON
    public const PAYLOAD = <<<JSON
{  
    "Email": "test@test.com",
    "FirstName": "test", 
    "LastName": "test",  
    "Position": "test",  
    "PhoneNumber": "98765432123", 
    "MobilePhone": "8179186432",
    "Status": "ACTIVE" 
}
JSON;
}

class Client
{
    public function call(
        string $url = Configuration::URL,
        $payload = Configuration::PAYLOAD,
        string $action = Configuration::ACTION
    ): ?object
    {
        if (is_array($payload)) {
            $payload = json_encode($payload);
        }
        if (!empty($payload)) {
            // SoapClient works with objects(StdClass)
            $payload = json_decode($payload);
        }

        $soapClient = $this->getClient($url);
        $sessionId = $this->getSession($soapClient);
        $args = array_filter([$sessionId, Configuration::PARTNER_UUID, $payload]);

        return $soapClient->$action(...$args);
    }

    public function getClient(string $url): SoapClient
    {
        return new SoapClient(
            $url . '?wsdl',
            [
                'location' => $url,
                'cache_wsdl' => WSDL_CACHE_NONE,
            ]
        );
    }

    public function getSession(SoapClient $client)
    {
        $date = gmdate('Y-m-d H:i:s');
        $merchantCode = Configuration::MERCHANT_CODE;
        $key = Configuration::MERCHANT_KEY;
        $string = strlen($merchantCode) . $merchantCode . strlen($date) . $date;
        $hash = hash_hmac('md5', $string, $key);
       // $client->__setCookie('XDEBUG_SESSION', 'PHPSTORM');
        return $client->login($merchantCode, $date, $hash);
    }
}

try {
    $client = new Client();
    var_dump($client->call());
} catch (Exception $ex) {
    var_dump($ex);
}

Response

{
    "UUID": "95d59280-3b7d-4d5b-8b9f-7b66fe900045",
    "Email": test@test.com,
    "FirstName": "test2",
    "LastName": "test2",
    "Position": "test2",
    "PhoneNumber": "98765432123",
    "MobilePhone": null,
    "Status": "ACTIVE"
}

 

Payment flow with Apple Pay

Overview

The following payment method is specific to Apple devices.

Availability

Available for all 2Checkout merchants (2Sell, 2Subscribe, 2Monetize & 4Enterprise) using all or any of our ordering engines (hosted shopping cart, ConvertPlus, and InLine).

For more information on availability, see the main documentation page for Apple Pay here.

Requirements

Shoppers can use any device that supports Apple Pay and is located in one of the selected list of countries.

For more information on requirements, see the main documentation page for Apple Pay here.

Activation

For activation, you need to have Apple Pay enabled on your 2Checkout account. Contact the Merchant Support team in order to enable this. After 2Checkout sets up our domain, we will provide you with a domain verification file.

Host your domain verification file at the following path on our server: https://[DOMAIN_NAME]/.well-known/apple-developer-merchantid-domain-association.

Setting up Apple Pay

To set up Apple Pay, you need to build the frontend component and to initialize the session using the startApplePaySession method providing the “validationUrl” to the payload. Once the token is received from the frontend component, it has to be sent to the decryptApplePayData endpoint in the 2Checkout API. This will return a data response from Apple Pay that needs to be used in the placeOrder call.

Frontend component

In order to set up an Apple Pay session in the shopper’s browser, the following steps are needed:

  1. Include the Apple Pay library.

    <script src=https://applepay.cdn-apple.com/jsapi/v1/apple-pay-sdk.js></script>
  2. Add the Apple Pay button.

    <div class="apple-pay-button apple-pay-button-black" onclick="onApplePayButtonClicked()"></div>
    <style>
        .apple-pay-button {
            display: inline-block;
            -webkit-appearance: -apple-pay-button;
            -apple-pay-button-type: buy; /* Use any supported button type. */
        }
        .apple-pay-button-black {
            -apple-pay-button-style: black;
        }
        .apple-pay-button-white {
            -apple-pay-button-style: white;
        }
        .apple-pay-button-white-with-line {
            -apple-pay-button-style: white-outline;
        }
    </style>
    
  3. Set up the Apple Pay function and create a session instance.

    function onApplePayButtonClicked() { 
        // Ensure browser supports Apple Pay
        if (!ApplePaySession) {
            return;
        }
    
        // Define ApplePayPaymentRequest
       /* Define the country code and currency being sent to the library, as well as 
       the list of supported networks and the descriptor and amount of the transaction.*/
        const request = {
            "countryCode": "US",
            "currencyCode": "USD",
            "merchantCapabilities": [
                "supports3DS"
            ],
            "supportedNetworks": [
                "visa",
                "masterCard",
                "amex",
                "discover"
            ],
            "total": {
                "label": "Example Transaction",
                "type": "final",
                "amount": "0.01"
            }
        };
    
        // Create ApplePaySession
        const session = new ApplePaySession(3, request);
    
        session.onvalidatemerchant = async event => {
            // Call your own server to request a new merchant session (call 2checkout API /rest/6.0/payments/startapplepaysession)
            fetch("/startApplePay.php")
                .then(res => res.json()) // Parse response as JSON.
                .then(merchantSession => {
                    response = JSON.parse(merchantSession.ApplePaySessionData.response);
                    session.completeMerchantValidation(response);
                })
                .catch(err => {
                  console.error("Error fetching merchant session", err);
                });
        };
    
        session.onpaymentmethodselected = event => {
            // Define ApplePayPaymentMethodUpdate based on the selected payment method.
            // No updates or errors are needed, pass an empty object.
            const update = {
                newTotal: {
                    label: "Demo (Card is not charged)",
                    type: "final",
                    amount: "0.01"
                }
            }
            session.completePaymentMethodSelection(update);
        };
    
        session.onshippingmethodselected = event => {
            // Define ApplePayShippingMethodUpdate based on the selected shipping method.
            // No updates or errors are needed, pass an empty object. 
            const update = {
                newTotal: {
                    label: "Demo (Card is not charged)",
                    type: "final",
                    amount: "0.01"
                }
            }
            session.completeShippingMethodSelection(update);
        };
    
        session.onshippingcontactselected = event => {
            // Define ApplePayShippingContactUpdate based on the selected shipping contact.
            const update = {
                newTotal: {
                    label: "Demo (Card is not charged)",
                    type: "final",
                    amount: "0.01"
                }
            }
            session.completeShippingContactSelection(update);
        };
    
        session.onpaymentauthorized = event => {
            // Call your own server to request the Apply Pay token decryption and pass the decoded token to the place order call (call 2checkout APIs /rest/6.0/payments/decryptapplepaydata and /rest/6.0/orders/)
            // Define ApplePayPaymentAuthorizationResult based on the place order response
            payload = {
                token: event.payment.token,
            };
            fetch("/finishApplePay.php", {
                method: "POST",
                headers: {"Content-Type": "application/json"},
                body: JSON.stringify(payload),
            }).then((res) => res.json())
                .then((res) => {
                    if (res.Status.includes('AUTHRECEIVED', 'COMPLETE')) {
                      session.completePayment(session.STATUS_SUCCESS);
                    }
                    console.log("INFO - RECEIVED ECOM RESPONSE: ", res.Status);
                    })
                    .catch((err) => console.log(err));
        };
    
        session.oncancel = event => {
            // Payment cancelled by WebKit
        };
        session.begin();
    }
    

Backend component

  1. Initiate an Apple Pay session.

    Create an endpoint on your server to call to initiate an Apple Pay session. In order for a valid Apple Pay session to be created, an API call to the 2Checkout API needs to be sent, with the validationURL set to the ApplePay payment service.

    Protocol

    Endpoint

    REST POST https://api.2checkout.com/rest/6.0/payments/startapplepaysession
    JSON-RPC startApplePaySession
    SOAP startApplePaySession

    startApplePaySession payload

    {
       "validationURL":"https://apple-pay-gateway.apple.com/paymentservices/startSession"
    }
  2. Decrypt the Apple Pay token.

    Once the token is received from the frontend component, it has to be sent to the decryptApplePayData endpoint in the 2Checkout API. This will return a data response from Apple Pay that needs to be used in the placeOrder call.

    Protocol

    Endpoint

    REST POST api.2checkout.com/rest/6.0/payments/decryptapplepaydata
    JSON-RPC decryptApplePayData
    SOAP decryptApplePayData

    decryptApplePayData payload

    BODY: (ApplePayData property value should be the event.payment.token from the onpaymentauthorized event)

    {
       "ApplePayData":"543a07601ed9f8b8ee226e9630a24e2a91da8fdb08e6786fa02bf628f395bb91"
    }
  3. Place the order.

    Once the Apple Pay data is received from 2Checkout, this needs to be used in the Payment Method object of the Payment Details object in the API call to place an order.

    Protocol

    Endpoint

    REST POST https://api.2checkout.com/rest/6.0/orders
    JSON-RPC placeOrder
    SOAP placeOrder
    {
       "Items":[
          {
             "Code":"5DCB30C6B0",
             "Quantity":1
          }
       ],
       "BillingDetails":{
          "Email":"example@email.com",
          "FirstName":"Customer First Name",
          "LastName":"Customer Last Name",
          "CountryCode":"US",
          "State":"California",
          "City":"San Francisco",
          "Address1":"Example Street",
          "Zip":"90210"
       },
       "PaymentDetails":{
          "Type":"APPLE_PAY",
          "Currency":"USD",
          "CustomerIP":"10.10.10.10",
          "PaymentMethod":{
             "ApplePayToken":"ApplePayDataToken"
          }
       },
       "Language":"en",
       "Country":"US",
       "CustomerIP":"10.10.10.10",
       "Source":"Website",
       "ExternalCustomerReference":"externalCustomerId",
       "Currency":"USD",
       "MachineId":"123456789"
    }

Compliance trial email

Overview

2Checkout automatically sends out the Compliance trial email to shoppers with confirmation and details on their trial – information regarding trial period duration, trial expiration, following billing date, following billing amount, and a link to myAccount for the shopper to be able to cancel the following automatic charge.

Availability

All 2Checkout accounts.

Workflow

2Checkout sends the Compliance trial email if you offer free or promotional trial subscriptions, to prevent charge disputes and ensure compliance with the card networks’ requirements. Additional details can be found in the official published requirements.

Compliance trial email content

When a customer enrolls for a free or promotional period trial, the following information must be included in the email:

  • Trial period duration
  • Trial expiration
  • Following billing date
  • Following billing amount
  • A link to myAccount for the shopper to be able to cancel the following automatic charge

Sample compliance trial email notification

visa compliance trial email

Is this the only email my shoppers receive after placing an order?

2Checkout can send the electronic delivery email either standalone or combined with the payment receipt notification (in one single email).

Depending on your account's setup, for each order containing at least one product configured with 2Checkout delivery your shoppers can receive:

  • Default: One email containing both the payment receipt and the electronic delivery messages
  • Two email notifications: The payment receipt and the electronic delivery messages, separately
  • Three email notifications: An order confirmation email, plus the payment receipt and the electronic delivery messages, separately

Contact 2Checkout to change your default configuration if you find another setup better suited for your customers.

Preview and test email

To preview and test the subscription email notification template, follow these steps:

  1. Log in to your 2Checkout Merchant Control Panel.
  2. Navigate to Marketing tools -> Email editor
  3. Scroll down to the Shopper emails section and click on Order
  4. Access the Compliance trial email under the Order section. You can access this email only if your account uses the default shopper emails communication setup that blends together the electronic delivery and the payment emails.

Compliance subscription email

Overview

2Checkout automatically sends out the Compliance subscription email to shoppers with confirmation and details on their subscription – information regarding billing cycle duration, next billing amount, next billing date, and a link to myAccount for the shopper to be able to cancel the following automatic charge.

Availability

All 2Checkout accounts.

Workflow

2Checkout sends the Compliance subscription email if the shopper has a recurring subscription-based product, to prevent charge disputes and ensure compliance with the card networks’ requirements. Additional details can be found in the official published requirements.

Subscription Email Notification Content

When a shopper enrolls for a recurring subscription-based product, the following information must be included in the email notification:

  • Billing cycle duration
  • Next billing amount
  • Next billing date
  • A link to myAccount for the shopper to be able to cancel the following automatic charge

Sample subscription email notification

subscription email notification

Is this the only email my shoppers receive after placing an order?

2Checkout can send the electronic delivery email either standalone or combined with the payment receipt notification (in one single email).

Depending on your account's setup, for each order containing at least one product configured with 2Checkout delivery your shoppers can receive:

  • Default: One email containing both the payment receipt and the electronic delivery messages
  • Two email notifications: The payment receipt and the electronic delivery messages, separately
  • Three email notifications: An order confirmation email, plus the payment receipt and the electronic delivery messages, separately

Contact 2Checkout to change your default configuration if you find another setup better suited for your customers.

Preview and test email

To preview and test the subscription email notification template, follow these steps:

  1. Log in to your 2Checkout Merchant Control Panel.
  2. Navigate to Marketing tools -> Email editor
  3. Scroll down to the Shopper emails section and click on Order
  4. Access the Compliance subscription email under the Order section. You can access this email only if your account uses the default shopper emails communication setup that blends together the electronic delivery and the payment emails.

PayPal Service Provider for 2Checkout

Overview

PayPal Service Provider is a new self-service PayPal solution offered to merchants signed on our PSP model, allowing for multiple payment options to be available under the same high-conversion shopping carts.

Availability

Merchants eligible for the PayPal Service Provider need to meet the following criteria:

  • Business Model: Payment Service Provider (PSP)
  • Merchant country:  Austria, Belgium, Bulgaria, Croatia, Republic of Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, and Sweden.

Prerequisites

Merchants need to have or create a valid PayPal business account.

If you don't have a PayPal account, follow this Sign up. If you already have an account, simply Log in

Workflow

To be able to accept payments via PayPal in your 2Checkout account, you first need to generate the API credentials from your verified PayPal account dashboard. In order to do this, perform the following steps.

PayPal Settings

  1. Log in to your PayPal account.
  2. Navigate to Account Settings > Account access
  3. On the Account access page, click on Update next to API access.

PayPal Service Provider for 2Checkout 9

4. On the next page, scroll down to NVP/SOAP API integration and click on Manage API credentials. 

PayPal Service Provider for 2Checkout 4

5. PayPal will then generate API Credentials that you can use in your 2Checkout account.

 

To complete setting up PayPal in your 2Checkout account, you will need to collect and use the following credential information: 

  • API Username 
  • API Password 
  • Signature 

PayPal Service Provider for 2Checkout 5

2Checkout Settings

1. Once you have identified your PayPal credentials, log in to your 2Checkout Merchant Control Panel account.

2. Navigate to Setup > Ordering options and click on the Payment methods tab.

PayPal Service Provider for 2Checkout 6

3. On the Payment methods page, click on the Settings cogwheel next to the PayPal payment option.

PayPal Service Provider for 2Checkout 1

4. On the PayPal payment settings page paste the credentials you copied previously from the PayPal admin.

  • API Password
  • API Signature
  • API Username

PayPal Service Provider for 2Checkout 8

5. Click Save. You can now accept payments via PayPal in your 2Checkout account. 

Reference Transactions

 
If you are selling subscription-based products or services or you are looking to improve the shopping experience for returning customers using 2Checkout, make sure that reference transactions are enabled for your PayPal business account.
 
Payments through reference (the reference of the billing agreement) are not available by default in PayPal business accounts. To activate this feature, you need to contact PayPal and request the enablement of reference transactions.
 
   Please note that it is up to PayPal to validate if certain requirements are met or not, before it enables support for reference transactions for your account.
 

How to collect churn reasons

Overview

Any effort to understand how churn occurs starts with a simple questions: where is churn coming from and why? Here are some ways to collect data for voluntary churn, which will later be made available in the churn reports that are currently under construction. 

Collect churn reasons via the Merchant Control Panel 

When canceling a subscription or stopping the automatic billing via the subscription page in the Merchant Control Panel, you are presented with the option to select one or multiple churn reasons.  

If you choose to cancel the subscription immediately, a confirmation pop-up is displayed, along with the possibility of selecting the cancellation reason: 

how to collect churn reasons 1

Providing the reason for cancellation is not mandatory, however if you want to be able to track churn metrics in the future, this could help you get more comprehensive reporting data.

If you stop the automatic billing, you can either choose to disable it right away or after a number of renewals. However, you can only specify the cancellation reason if you end automatic billing effective immediately.

how to collect churn reasons 2

Churn reasons

There are different churn reasons available depending on whether the subscription is disabled or the automatic billing is stopped:

Churn reason Cancel subscription Stop automatic billing
Not satisfied with the product/service Yes Yes
Don’t need the product/service anymore Yes Yes
Covid-19 Yes Yes
Price is too high Yes Yes
Not satisfied with customer support Yes Yes
Accidentally enabled auto-renewal No Yes
Prefer to manually renew my subscription No Yes
Already renewed my subscription No Yes
Don’t need the product/service anymore Yes Yes
Want to pause my subscription No Yes
Others - please specify Yes Yes

Collect churn reasons via 2Checkout MyAccount

Shoppers can specify the reason they wish to stop the automatic billing if they do it via their 2Checkout MyAccount platform. This applies to both subscriptions that have an active churn prevention campaign and to those that do not, with some workflow differences.

All shoppers that click on the “Stop automatic subscription renewal” link (and there is no churn prevention campaign attached to the subscription) get a confirmation pop-up where they can specify the reason for this change.

how to collect churn reasons 3

how to collect churn reasons 4

If a churn prevention campaign is already attached to the subscription, then the “Stop automatic subscription renewal” option is no longer displayed as a churn reason as in the example above. Instead, the shopper is prompted with the configured churn prevention campaign steps.

Next steps

We are currently working on a new churn report that will make this type of data available in a seamless way and will help you understand why customers leave a product/service.

Return Process

Approved URL

After the successful completion of a sale, 2Checkout.com can return the buyer and sale parameters to a script or page on your site. Specifying an approved URL at the account level will direct all buyers to the same URL after a successful checkout. This URL can be entered on the Site Management page by clicking the Account tab followed by the Site Management sub-category.

site management

You may also choose to pass the approved URL on the fly by using the x_receipt_link_url parameter.  This parameter has a few very specific behaviors that should be paid attention so that it can be used effectively.

x_receipt_link_url=http://www.yoursite.com/return
  • This parameter will over-ride any approved URL set within your account.
  • If your return method is set to Given links back to my Site — This parameter will control where the Click Here to Finalize your Order button takes the buyer after the successful sale.
  • If your return method is set to Direct Return or Header Redirect, this parameter will control where the buyer gets directed to automatically after the successful sale.
  • The value passed must match the domain registered to the account.

Validation

The MD5 hash is provided to help you verify the authenticity of the passback to your approved URL. The hash is computed using the secret word on the Site Management page and is returned using the key parameter. To validate against the hash, you need to make a string that contains the information described below and pass it in as the value to your scripting languages MD5 function. The MD5 hash is created the same way for a production 2Checkout account and a Sandbox 2Checkout account.

 UPPERCASE(MD5_ENCRYPTED(Secret Word + Seller ID + order_number + Sale Total)) 

The secret word is set by yourself on the Site Managment page. The vendor number is your numerical vendor/seller ID number. The order number is the order number for the sale. The total is the numerical value for the total amount of the sale.Each of our community supported libraries provides a binding to validate the hash on a notification message.

Demo Sales

Please note that the MD5 hash that we return on demo sales is intentionally broken as we use a “1” for the order number when we compute the hash instead of the actual value being returned through the `order_number` parameter. You will need to account for this on your end if you are testing with demo sales by computing the compare hash like below:

UPPERCASE(MD5_ENCRYPTED(Secret Word + Seller ID + 1 + Sale Total))

 

Example

Below is an example PHP script that validates the hash.

<?php
$hashSecretWord = 'tango'; //2Checkout Secret Word
$hashSid = 1303908; //2Checkout account number
$hashTotal = '1.00'; //Sale total to validate against
$hashOrder = $_REQUEST['order_number']; //2Checkout Order Number
$StringToHash = strtoupper(md5($hashSecretWord . $hashSid . $hashOrder . $hashTotal));

if ($StringToHash != $_REQUEST['key']) {
	$result = 'Fail - Hash Mismatch'; 
	} else { 
	$result = 'Success - Hash Matched';
}

echo $result;

Return Method

2Checkout provides three methods in which the buyer and sale parameters can be returned to your approved URL. You may send the buyer to our order processed page which will display a Click Here to Finalize your Order button to redirect the buyer, you may bypass the order processed page using a header redirect or you can immediately display your approved URL to the buyer while they remain on our server. Your return method can be selected on the Site Management page.

Given links back to my Website

With the Return Method set to Given links back to my website, the buyer will be taken to our Order Processed page after completing a successful purchase. This page will feature a Click Here to Finalize your Order button. When clicked the buyer and collected sale parameters will be directed to the provided approved URL by POST.

Direct Return

With the Return Method set to Direct Return, sale parameters will be posted automatically to the approved URL while fetched by our server and displayed to the buyer. When using this Direct Return function the URL will be masked to the buyer, appearing to still be on the 2Checkout.com domain. This method can be used with redirects as long as each page outputs content more than 255 characters to the browser. If Direct Return encounters a page that redirects without outputting content the process will fail and the buyer will be sent to our standard Order Processed page. This occurs usually with a header redirect, specifically content less then 255 characters. This is a common issue as many developers will set their approved URL to a script that processes the return sales parameters then silently forwards the buyer to another page. This is usually a thank you or download page for intangible products. The best solution is to handle all post-order processing on the page set as your approved URL, including the thank you message. If no redirects are used, meaning the URL is masked by our servers, then relative links will not point to the correct location. This can be corrected with the use of absolute paths on the approved URL page or by simply using a base tag in the head of the document to provide a reference for the relative paths.

Header Redirect

With the Return Method set to Header Redirect the buyer will be immediately returned to your approved URL. Using this method, the sale parameters will be returned along with the buyer using the GET method.

Additional Information

If you are returning the buyer to a script on your end it is important to note that parameter information will typically be returned by POST. Parameters however will be returned by GET if the Header Redirect method is used.

   You must also have a script set up as the return URL if you wish to receive the pass back information. If your return URL ends in any of the following extensions, then pass back will NOT occur, but the buyer will still be returned there : .htm, .html, .com, .zip, .pdf, .rar, .doc
   If you do not specify an approved URL at the account level, product level, or with the x_receipt_link_url parameter the buyer will remain on the 2Checkout Order Processed page upon completion of the order.

 

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