Remote Transaction Administration allows merchants to manage payment transactions and gateway operations by submitting an HTTP POST request containing the required transaction variables. The system returns a URL-encoded response string that can be parsed programmatically.
This method is also used by available API/COM libraries and serves as the reference implementation for request and response name/value pairs.
https://pay1.plugnpay.com/payment/pnpremote.cgi
Remote Transaction Administration requests require:
Server IP addresses can be registered through the Security Administration menu within the merchant administration interface.
All requests submitted to the Remote Transaction Administration endpoint must adhere to the following rules:
The Remote Transaction Administration interface provides a consistent integration layer across supported client libraries, enabling standardized transaction management and response handling.
⚠️ Important: Include only the fields you plan to define; omit any unused fields.
⚠️ Recommended: Use the notify-email variable to receive automatic notifications regarding potential security or data validation issues.
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.
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.
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.
A Batch Auth request is a way to perform multiple auth’s with one request to the server.
A Commit Batch request is a way to perform multiple postauth’s with one request to the server.
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.
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.
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.
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.
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.
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.
The Payment operation functions similarly to a credit transaction and is used to issue funds back to a cardholder. This mode is restricted to specific processors and card types.
A Query request is used to obtain the transaction history of a specific orderID with the specified date range.
An ACH/eCheck Query operation retrieves transaction records related to ACH/eCheck activity, including the ability to review possible customer banking changes. It supports querying by order ID or date range.
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.
This mode is used when issuing a return using billing information from a previous authorization based on the submitted prevorderid and origorderid. Billing data is valid for 2 years. The return will bear a new orderID, either that submitted or gateway-generated.
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.