Section 2. Remote Transaction Administration

Several administration functions can also be controlled remotely using one of the API/COM/CFX libraries available or by calling the URL shown below using your own library. In addition to a valid username and password, the IP address of the server making the transaction requests needs to be registered prior to commencing transactions. Registering the IP addresses of your server(s) can be performed via the Security Administration Menu accessible from the main administration area.

Payment URL: https://{secure-payment-server-domain}/payment/pnpremote.cgi

The value for “{secure-payment-server-domain}” is assigned to you upon registration and is the domain of the payment gateway.

The administration functions that can be called with the remote client are as follows:

• Mark - Marking a transaction, recorded in the system as a postauth, is a request to settle the transaction. Transactions that are postauthed are swept to the bank for transfer of funds. A transaction can be settled for an amount up to but not greater than the amount of the original authorization. For a transaction to settle for an amount less than the original sale amount it needs to have an auth reversal or reauth performed. If a mark request for an amount less than the original sale is received, the system will automatically converted the transaction request to a reauth transaction and then mark it for settlement.

• Void - Voiding a transaction is a cancellation request. A void can be performed on auth, postauth, or return transactions. A void is applied to the most recent previous transaction of one of these types. A void against an auth will prevent the auth from being marked for settlement. An auth can be voided anytime prior to it being postauthed. A void against a return or postauth will prevent the transaction from being swept to the bank. A return or postauth can be voided only prior to the transaction being swept to the bank which is once a day. The time of day a transactions is swept varies per processor.

• Return - A return is a credit transaction associated with a prior auth. A return can be made for an amount less than or equal to the amount of the original auth. Only one return may be performed per transaction even if the amount of the return is less than the amount of the original auth.

• Return (older than 1 year) - This mode is to be used when issuing a return to a customer whose auth is older than 1 year. This operation will use the billing information from the previous authorization based on the submitted ‘prevorderid’. The return will bear a new orderID, either that submitted or gateway-generated.

• Credit - A credit transfers funds from a merchant’s account and is a not associated with any prior auth. A credit can be made for any amount. For security reasons an account can be flagged to prevent credits from being issued. Turning off the ability for an account to allow credits can be done via the Security Administration Area.

• Auth Reversal - A reauth is a request to settle a transaction at a lower dollar amount than the original authorization. This same functionality can be performed by performing a mark for a dollar amount less than the original auth amount.

• Re-Authorization - This creates a new authorization based on information from a previous transaction. This is useful if you do not want to resubmit credit card information or if your processor does not support Auth Reversals. The original orderID is required.

• Re-Return - This creates a new return based on information from a previous transaction. This is useful if you do not want to resubmit credit card information or need to submit multiple returns on the same orderID. The original orderID is required.

• Force Auth - A force auth is used to enter an authorization into the system when an auth code has been previously obtained - typically via a phone call to the voice authorization center of your merchant account provider.

• Assemble Batch - This transaction type is a query transaction type only. It returns a list of orderID’s of transactions that have been previously authorized but not yet settled or voided. This transaction would typically be used in conjunction with a Commit Batch transaction.

• Commit Batch - A Commit Batch request is a way to perform multiple postauth’s with one request to the server.

• Batch Auth - A Batch Auth request is a way to perform multiple auth’s with one request to the server.

• Query - A Query request is used to obtain the transaction history of a specific orderID with the specified date range.

• Batch Upload - A Batch Upload request is used to upload to the system a flat file of transaction that you wish to have processed. The file can contain a mixture of authorizations, returns, postauths, etc. Files uploaded in this manner or through the Transaction Administration Area are processed offline and an email is sent upon completion with a URL pointing to a results file.

• Batch Review - A Batch Review request is used to retrieve the delimited results of the Batch Upload you have previously submitted. You would use this feature, only after you have received notification that your uploaded file has been processed.

• Check Card - This mode submits a 1.00 authorization (by default; see details below); if it is successful, the authorization is voided. This is useful to determine the validity of a card and information submitted with it, such as CVV and address information. The customer is not charged.

IMPORTANT NOTE: We HIGHLY RECOMMEND using the ‘Remote Client Password’ feature of the Security Administration area to create a password exclusively for remote API usage. This newly created password can then be used for the value of the variable ‘publisher-password’. By doing so, you will be able to change your administration login information without impacting your software. We also HIGHLY RECOMMEND the use of the variable ’notify-email’ which will automatically alert you to security issues with your submitted data.