Getting Started

Fraud Protection

Custom forms are not protected by Click & Pledge's fraud protection guarantee since reCAPTCHA cannot be enforced.  Please make sure the forms are tested against credit card validation robo-attacks.  By using the API you are accepting complete responsibility for all fraudulent transactions.

The following are a few examples of the XML’s that apply to typical applications.   If you wish to see a specific example please email us at support@clickandpledge.com and describe the applications and one of our engineers will gladly work on the example for you.  For simpler forms you may want to consider using FaaS platform. To prevent spam and fraudulent attacks on webforms that use Click & Pledge’s API all forms must include reCAPTCHA to validate patrons.

• Example 1*:  Minimum fields [e.g. simple donation or a single product]
• Example 2:  Minimum fields with eCheck
• Example 3:  Minimum fields with custom questions
• Example 4:  Minimum fields with third party nodes: ConstantConatact,  MailChimp, Salesforce, Twitter
• Example 5:  A product with eTicket (minimum options)
• Example 6:  1 product with eTicket for two quantities (complete options)
• Example 7:  A product with name badge
• Example 8:  A product with shipping information
• Example 9:  Multiple products with every node included
• Helpful hints

All examples in one download:  PaaS-Examples.zip^*

^* IMPORTANT:  All samples use dummy data and should be replaced with valid information.  It is important that all data be valid, including such nodes as IP, since invalid data will result in blocking of the transaction & decline, either by the internal fraud check or the gateway validation checks.

* For simple applications, such as Example 1, you may want to consider using the FaaS platform.  FaaS provides majority of the PaaS features and works based on the form’s POST method without any need for XML.  The only features not included in the FaaS platform are eTicket and name badges.

Example 1

The following example demonstrates the least number of fields needed for processing a donation.

• Sample XML:  Minimum donation fields

Points to consider:

• Donations are the same as products except that the quantity listed is 1
• Using a Checkout page ID (WID) helps with setting up receipt header information.
• IPAddress:  The IP address of the person making the payment.  The IP will be used for fraud analysis and it is important that a correct IP address is used.
• <OrderMode>:  While testing keep the mode as “Test”.  Once you are ready to go into product change the mode to “Production”.  In Test mode the test credit card will work and real cards will decline.
• <Total> should be posted in pennies.  $2 should be posted as 200

Example 2

eCheck option is in addition to the credit card payment methods and may be applied for separately.  eCheck requires additional applications with our issuing partner.

• Sample XML:  Minimum donation fields + eCheck

Points to consider:

• Donations are the same as products except that the quantity listed is 1
• Using a Checkout page ID (WID) helps with setting up receipt header information.
• IPAddress:  The IP address of the person making the payment.  The IP will be used for fraud analysis and it is important that a correct IP address is used.
• <OrderMode>:  While testing keep the mode as “Test”.  Once you are ready to go into product change the mode to “Production”.  In Test mode the test credit card will work and real cards will decline.
• <Total> should be posted in pennies.  $2 should be posted as 200

Example 3

Custom questions are additional questions that may be asked from the patron during the checkout process.  There are no limits on the number of custom questions that may be passed on to the API.  Custom questions will be saved and will be included in the receipt.

Sample XML:  Minimum donation fields + 3 custom questions

Points to consider:

• Donations are the same as products except that the quantity listed is 1
• Using a Checkout page ID (WID) helps with setting up receipt header information.
• IPAddress:  The IP address of the person making the payment.  The IP will be used for fraud analysis and it is important that a correct IP address is used.
• <OrderMode>:  While testing keep the mode as “Test”.  Once you are ready to go into product change the mode to “Production”.  In Test mode the test credit card will work and real cards will decline.
• <Total> should be posted in pennies.  $2 should be posted as 200
• There are no limits on the number of times the <CustomField> node may be repeated.

Example 4

There are 2 different methods to use the Third Party nodes.  The simplest method is by taking advantage of a Classic checkout page.  The API provides appropriate nodes to pass the UserID & Password for each of the integrated third party applications, but if you don’t wish wish to include the information in the posted XML you may add it to the account and enable the application with the checkout page.

Here are 4 examples:

• Example 4a: Using third party nodes with the userid & password
• Example 4b: Using third party nodes without the userid & password
• Example 4c: Using only Twitter post
• Example 4d: Using only Constant Contact

Points to Consider:

• Donations are the same as products except that the quantity listed is 1
• Using a Checkout page ID (WID) helps with setting up receipt header information.
• IPAddress:  The IP address of the person making the payment.  The IP will be used for fraud analysis and it is important that a correct IP address is used.
• <OrderMode>:  While testing keep the mode as “Test”.  Once you are ready to go into product change the mode to “Production”.  In Test mode the test credit card will work and real cards will decline.
• <Total> should be posted in pennies.  $2 should be posted as 200
• There are no limits on the number of times the <CustomField> node may be repeated.
• There are no limits on the number of times the <ListName> may be used.  If the user subscribes to multiple lists then the <ListName> node should be repeated for each subscription.  Both Constant Contact & MailChimp may be used individually or together.
• If Salesforce is active in the administrative system the API will use the Salesforce creditentials as listed in the account setting.  There is no need to include the same credential again.
• Twitter posts are limited to 140 characters, which is a limit set by Twitter.
• ClickandPledge social networking node will be used for comments that will be returned by the RaaS services. Read more

Example 5

With eTicket option, the payment receipt will include a PDF document of an eTicket.  The example includes the minimum fields required for an eTicket.

• Sample XML:  Single product with eTicket option

Points to Consider:

• Using a Checkout page ID (WID) helps with setting up receipt header information.
• IPAddress:  The IP address of the person making the payment.  The IP will be used for fraud analysis and it is important that a correct IP address is used.
• <OrderMode>:  While testing keep the mode as “Test”.  Once you are ready to go into product change the mode to “Production”.  In Test mode the test credit card will work and real cards will decline.
• <Total> should be posted in pennies.  $2 should be posted as 200
• To add a banner to the eTicket, set up a product and add a ticket to the product.  Use the Ticket ID in the API for <TicketID> node.  The banner used in the ticket will be used for the eTicket.pdf file which will be emailed with the receipt.
• The 2 nodes:  <SecurityCode> & <SerialNo> are described in the manual. 
• If an item has a ticket then there has to be a ticket node for each quantity sold.

Example 6

Sending detailed and well designed eTickets requires addition of a couple of more nodes than the ones shown in Exmaple 5.  In this example all eTicket nodes are provided for purchase of 2 tickets.

• Sample XML:  2 eTickets puchased with detailed information

Points to Consider

• Using a Checkout page ID (WID) helps with setting up receipt header information.
• IPAddress:  The IP address of the person making the payment.  The IP will be used for fraud analysis and it is important that a correct IP address is used.
• <OrderMode>:  While testing keep the mode as “Test”.  Once you are ready to go into product change the mode to “Production”.  In Test mode the test credit card will work and real cards will decline.
• <Total> should be posted in pennies.  $2 should be posted as 200
• To add a banner to the eTicket, set up a product and add a ticket to the product.  Use the Ticket ID in the API for <TicketID> node.  The banner used in the ticket will be used for the eTicket.pdf file which will be emailed with the receipt.
• The 2 nodes:  <SecurityCode> & <SerialNo> are described in the manual. 
• If an item has a ticket then there has to be a ticket node for each quantity sold.
• Each line in the ticket definition has a specific length requirement.  Please refer to the manual for details.

Example 7

Names badges may be sent with each purchase.  Name badges are similar to eTickets and will be sent as a PDF attachment to the receipt.

Sample XML:  Since product with nam badge and a quantity of 2 purchase.

Points to Consider

• • Using a Checkout page ID (WID) helps with setting up receipt header information.
• • IPAddress:  The IP address of the person making the payment.  The IP will be used for fraud analysis and it is important that a correct IP address is used.
• • <OrderMode>:  While testing keep the mode as “Test”.  Once you are ready to go into product change the mode to “Production”.  In Test mode the test credit card will work and real cards will decline.
• • <Total> should be posted in pennies.  $2 should be posted as 200
• • To add a banner to the name badge create a name badge as part of a product.  Use the Badge ID in the XML as shown in the sample XML:  <NameBadgeID>7610</NameBadgeID>
• • Customize each line of the name badge using the Footer & CustomFieldList.
• • Name badges should be defined for each quantity of a purchased product with name badge.
• • Footer may be 1 -3 lines while the custom questions have a limit of 2 questions.

Example 8

Shipping information is similar to billing information and includes the contact as well as the address information.

• Sample XML:  Single product with Biling & Shipping information

Points to consider:

• Donations are the same as products except that the quantity listed is 1
• Using a Checkout page ID (WID) helps with setting up receipt header information.
• IPAddress:  The IP address of the person making the payment.  The IP will be used for fraud analysis and it is important that a correct IP address is used.
• <OrderMode>:  While testing keep the mode as “Test”.  Once you are ready to go into product change the mode to “Production”.  In Test mode the test credit card will work and real cards will decline.
• <Total> should be posted in pennies.  $2 should be posted as 200

Example 9

This example includes all available fields except eCheck.  The payment method used in this example is credit card and since only one payment method may be used eCheck is not listed.

There are a number of elements that are included in any other example, such as discounts, etc.  Refer to the manual for detailed coverage of each node.

• Sample XML:  Complete listing of all nodes

Using Checkout Pages for various receipt settings

While the PaaS platform provides tremendous flexibilitywhere every aspect of a transaction may be posted through the XML, it also takes advantage of various features of checkout pages minimizing the number of nodes needed.  For example the following nodes may be omitted by providing the WID of a checkout page as a reference.

• The above nodes will be taken from the Checkout page if its WID is listed as:  <WID></WID>

The RECEIPT node will be as follows:

To take advantage of WID shortcut follow the steps listed below:

• Login to the administrative system
• Click on Checkout Pages
• Add or use an existing Classic page (any of the easy pages will work).
• Customise the following fields.  Other fields will be ignored.
• Thank you message:  Appears in the receipt after the salutation
• Terms & Conditions:  If applicable – appears at the bottom of the receipt.
• Email Notifications:  Listed emails will receive a copy of the email.  These emails are in addition to the emails set in the Account Info / Profile / Receipt – Email Notification
• Once completed copy the WID of the checkout page and use it in the API.

Enabling Third Party Integration

The API provides dynamic integration with the following third party platforms:

• Salesforce
• ConstantContact
• MailChimp
• Twitter

The nodes are listed under ThirdParty.  Each node requires UserID, Password, and a comment or list name to be posted to the provider.  Through the integration with the checkout page the UserID and Password of the provider may be omitted.   To take advantage of this shortcut follow the steps listed below.

• Login to the administrative system
• Click on Account Info / 3rd Party Tab
• Enable any of the accounts to be used in the API and update the UserID & Password for the appropriate accounts.
• Follow the steps listed before and add or use an existing checkout page.
• Edit the checkout page and enable the third party vendors applicable to the AP [Learn more]

Once activated the third patry nodes will take advantage of the Admin settings and use the UserID & P assword setting as set in the administrative system.  This feature provides an extra layer of security by not exposing the UserID & Password of these accounts in a configuration xml.

Using Adobe Flash with the PaaS platform

The PaaS platform has cross site scripting enabled allowing for Adobe Flash & Microsoft Silverlight applications to take advantage of the API.

The following provisions are made to help with Flash applications to work with the API.

• Based 64 encoded XML’s may be posted using:  OperationBase64Encode
• Enable cross site scripting and cross domain scripting.