This Standard Operating Procedure (SOP) describes the process for credit card processing against web orders or for B2B customer paying their account via IP1 web services.

This is sub-process following Payment Method Selection.

Procedure

It is your responsibility to ensure that you understand this procedure before performing the following tasks.

Note	Deviations from this procedure should be covered by procedures written by your company. Before performing any tasks please ensure all the business rules are set-up accordingly.

Process overview This section documents the Headline Processes for the web user to process payment using credit card. It assumes: Pre-requisite processes outlined in Payment Method Selection have already been done and the web user has selected credit card payment method.
Ordering scenario Following process assumes an initial pre-authorisation will be done against the credit card when order is taken and that IP1 will settle the funds later (as goods are supplied) utilizing token information returned form the Payment Gateway at this initial pre-authorisation step. Refer Additional Notes & Scenario variations for important notes on supported payment gateways and methods for capturing/processing the credit card. User selects freight and payment option and website executes updateHeader then viewCart to store the minAmountToPay Website retrieves payment requirements from retrievePaymentFields and presents user with payment entry form based on values returned. This step is generally redundant for credit card processing using 3^rd party payment gateway Credit Card entry/validation and retrieval of token: Website passes information & control to a 3^rd party payment gateway landing page (LP) such as Cybersource, Securepay or Curbstone), requesting a pre-authorisation transaction type. Web user key in credit card details on LP. LP will perform necessary validations and interactions with end user until a valid credit card has been entered. The LP interacts with your organisation’s bank to hold pre-authorisation against the web user’s credit card. LP passes back token & non-sensitive payment details such as credit card mask (eg. xxx-xxx-xxxx-1234) information back to website. Website executes makePayment passing token and other payment details returned from LP. For some Payment Gateways, the standard response fields outlined in retrievePaymentFields and makePayment do not cover the full set of payment data required to be sent back to IP1, or do not have sufficient field lengths. In that case, the website must execute captureGenericData with the necessary payment details specific to the relevant Payment Gateway implementation & response. Format and requirements of that response data will be documented by the Payment Gateway. Refer to an Iptor consultant for assistance with this.
Payment of account scenario For payment of account, immediate settlement against credit card is done via the Payment Gateway, once valid card details have been entered. Refer Additional Notes & Scenario variations for important notes on supported payment gateways and methods for capturing/processing the credit card. User selects outstanding invoice(s) to be paid. Website executes processInvoices Website presents web user with payment method options from processInvoices User selects payment option Website retrieves payment requirements from prepareAccountPayment and presents user with payment entry form based on values returned. This step is generally redundant for credit card processing using 3^rd party payment gateway Credit Card entry/validation and settlement: Website passes information & control to a 3^rd party payment gateway landing page (LP) such as Cybersource, Securepay or Curbstone), requesting a settlement transaction type. Web user key in credit card details on LP. LP will perform necessary validations and interactions with end user until a valid credit card has been entered. The LP interacts with your organisation’s bank to immediately settle funds against the web user’s credit card. LP passes non-sensitive payment details such as credit card mask (eg. xxx-xxx-xxxx-1234) information back to website. Website executes payInvoices passing payment details returned from LP. Once payment data has been collected, website executes payInvoices with those details to finalise the account payment. IP1 records this payment against the customer account, allocating against the nominated invoices. For some Payment Gateways, the standard response fields outlined in retrievePaymentFields and makePayment do not cover the full set of payment data required to be sent back to IP1, or do not have sufficient field lengths. In that case, the website must exectute captureGenericData with the necessary payment details specific to the relevant Payment Gateway implementation & response. Format and requirements of that response data will be documented by the Payment Gateway. Refer to an IP1 consultant for assistance with this.
Additional notes and scenario variations Pre-authorisation and settlement variations for orders IP1 allows different configurations for credit card handling to suit different business requirements scenarios. Options for initial credit card entry/validation are: Pre-authorisation for a nominal amount (validate on line) Default is $1, but this can be configured to other amounts Depending on Payment Gateway & Bank used, a zero dollar pre-authorisation amount may be accepted as a means of validating card and retrieving token, without holding any funds at all. Pre-authorisation for estimated amount Depending on the payment terms for this order, that could be: Invoice amount (value of goods that are available to be invoiced now) Order amount (value of total order, including any backordered items) Invoice amount plus nominated % of backorders (eg. Could require 50% pre-payment for backorders) Charge Requests immediate settlement for estimated amount (depending on payment terms as above) Typical set up & process is to: Do pre-authorisation when order is keyed/processed, then: Additional pre-authorisation check when goods are Released for Picking (configurable) If pre-authorisation fails at Release for Pick IP1 can hold order at “D” status with sub-category such as CC-FAIL to alert customer service & warehouse Accounts staff can then use the “Work with Failed Credit Card” to re-try existing credit card token, or contact the customer and request new payment details. If Release for Pick succeeds, then settle payment on credit card once order is picked & completed using token collected at step 1. Refer SOP Payment Manager for more information on setup & process requirements in IP1. Payment Gateway options There are many 3^rd party Payment Gateway options available in the market, but IP1 cannot support all of these. In release 78 and 79 of IP1, we currently support landing page (LP) functionality with: SecurePay CyberSource We expect to start building LP capability with Curbstone ‘C3’ product once that has GA (general availability) status. Our recommendation is that the website pass control to the 3^rd party Payment Gateway Landing Page to allow user to key credit card details. However, some gateways may allow alternative approach whereby their secure entry page may be embedded directly in your website. Previous IP1 versions In earlier versions of IP1, we allowed web site to collect & pass credit card details to IP1. IP1 would then validate, pre-authorise and settle through SSL secured interactions directly with nominated Payment Gateway for each implementation. From release 79 of IP1, however, we will not allow IP1 to ever see the sensitive credit card number at all. Therefore, we expect web sites to interact directly with supported Payment Gateway to validate, pre-authorise or settle credit card details. The web site will then only pass back non-sensitive details (eg. Token, last 4 digits of c/c#, etc.) from the Payment Gateway to IP1 via web services. IP1 will then use the token details to handle any subsequent pre-authorisation or settlement with the Payment Gateway.

Process overview

This section documents the Headline Processes for the web user to process payment using credit card. It assumes:

Pre-requisite processes outlined in Payment Method Selection have already been done and the web user has selected credit card payment method.

Ordering scenario

Following process assumes an initial pre-authorisation will be done against the credit card when order is taken and that IP1 will settle the funds later (as goods are supplied) utilizing token information returned form the Payment Gateway at this initial pre-authorisation step.

Refer Additional Notes & Scenario variations for important notes on supported payment gateways and methods for capturing/processing the credit card.

User selects freight and payment option and website executes updateHeader then viewCart to store the minAmountToPay
Website retrieves payment requirements from retrievePaymentFields and presents user with payment entry form based on values returned.
- This step is generally redundant for credit card processing using 3^rd party payment gateway
Credit Card entry/validation and retrieval of token:
- Website passes information & control to a 3^rd party payment gateway landing page (LP) such as Cybersource, Securepay or Curbstone), requesting a pre-authorisation transaction type.
- Web user key in credit card details on LP.
- LP will perform necessary validations and interactions with end user until a valid credit card has been entered.
- The LP interacts with your organisation’s bank to hold pre-authorisation against the web user’s credit card.
- LP passes back token & non-sensitive payment details such as credit card mask (eg. xxx-xxx-xxxx-1234) information back to website.
- Website executes makePayment passing token and other payment details returned from LP.
- For some Payment Gateways, the standard response fields outlined in retrievePaymentFields and makePayment do not cover the full set of payment data required to be sent back to IP1, or do not have sufficient field lengths. In that case, the website must execute captureGenericData with the necessary payment details specific to the relevant Payment Gateway implementation & response. Format and requirements of that response data will be documented by the Payment Gateway. Refer to an Iptor consultant for assistance with this.

Payment of account scenario

For payment of account, immediate settlement against credit card is done via the Payment Gateway, once valid card details have been entered.

Refer Additional Notes & Scenario variations for important notes on supported payment gateways and methods for capturing/processing the credit card.

User selects outstanding invoice(s) to be paid.
Website executes processInvoices
Website presents web user with payment method options from processInvoices
User selects payment option
Website retrieves payment requirements from prepareAccountPayment and presents user with payment entry form based on values returned.
- This step is generally redundant for credit card processing using 3^rd party payment gateway
Credit Card entry/validation and settlement:
- Website passes information & control to a 3^rd party payment gateway landing page (LP) such as Cybersource, Securepay or Curbstone), requesting a settlement transaction type.
- Web user key in credit card details on LP.
- LP will perform necessary validations and interactions with end user until a valid credit card has been entered.
- The LP interacts with your organisation’s bank to immediately settle funds against the web user’s credit card.
- LP passes non-sensitive payment details such as credit card mask (eg. xxx-xxx-xxxx-1234) information back to website.
Website executes payInvoices passing payment details returned from LP.
Once payment data has been collected, website executes payInvoices with those details to finalise the account payment. IP1 records this payment against the customer account, allocating against the nominated invoices.
For some Payment Gateways, the standard response fields outlined in retrievePaymentFields and makePayment do not cover the full set of payment data required to be sent back to IP1, or do not have sufficient field lengths. In that case, the website must exectute captureGenericData with the necessary payment details specific to the relevant Payment Gateway implementation & response. Format and requirements of that response data will be documented by the Payment Gateway. Refer to an IP1 consultant for assistance with this.

Additional notes and scenario variations

Pre-authorisation and settlement variations for orders

IP1 allows different configurations for credit card handling to suit different business requirements scenarios.

Options for initial credit card entry/validation are:

Pre-authorisation for a nominal amount (validate on line)
- Default is $1, but this can be configured to other amounts
- Depending on Payment Gateway & Bank used, a zero dollar pre-authorisation amount may be accepted as a means of validating card and retrieving token, without holding any funds at all.
Pre-authorisation for estimated amount
- Depending on the payment terms for this order, that could be:
  - Invoice amount (value of goods that are available to be invoiced now)
  - Order amount (value of total order, including any backordered items)
  - Invoice amount plus nominated % of backorders (eg. Could require 50% pre-payment for backorders)
- Charge
  - Requests immediate settlement for estimated amount (depending on payment terms as above)

Typical set up & process is to:

Do pre-authorisation when order is keyed/processed, then:
Additional pre-authorisation check when goods are Released for Picking (configurable)
If pre-authorisation fails at Release for Pick
- IP1 can hold order at “D” status with sub-category such as CC-FAIL to alert customer service & warehouse
- Accounts staff can then use the “Work with Failed Credit Card” to re-try existing credit card token, or contact the customer and request new payment details.
If Release for Pick succeeds, then settle payment on credit card once order is picked & completed using token collected at step 1.

Refer SOP Payment Manager for more information on setup & process requirements in IP1.

Payment Gateway options

There are many 3^rd party Payment Gateway options available in the market, but IP1 cannot support all of these. In release 78 and 79 of IP1, we currently support landing page (LP) functionality with:

SecurePay
CyberSource

We expect to start building LP capability with Curbstone ‘C3’ product once that has GA (general availability) status.

Our recommendation is that the website pass control to the 3^rd party Payment Gateway Landing Page to allow user to key credit card details. However, some gateways may allow alternative approach whereby their secure entry page may be embedded directly in your website.

Previous IP1 versions

In earlier versions of IP1, we allowed web site to collect & pass credit card details to IP1. IP1 would then validate, pre-authorise and settle through SSL secured interactions directly with nominated Payment Gateway for each implementation.

From release 79 of IP1, however, we will not allow IP1 to ever see the sensitive credit card number at all. Therefore, we expect web sites to interact directly with supported Payment Gateway to validate, pre-authorise or settle credit card details. The web site will then only pass back non-sensitive details (eg. Token, last 4 digits of c/c#, etc.) from the Payment Gateway to IP1 via web services. IP1 will then use the token details to handle any subsequent pre-authorisation or settlement with the Payment Gateway.