This feature can be used in the context of an automatic software download or automatic password protected access to a restricted area of your site. Anywhere where customer or order information must be used post-payment.
A working example can be found here
HTTP_REFERER
This feature should be used in conjunction with the HTTP_REFERER security information:
When a page or program is called from the web the referring page URL is passed via
the HTTP_REFERRER environment variable. The referring page information of the DirectOne receipt page will contain
HTTP_REFERRER="https://vault.safepay.com.au/cgi-bin/process_payment.pl/accountname"
where accountname is your DirectOne "vendor name". This information will only appear
when the page is called from the DirectOne server using your specified account. Any
script that is called from the return_link_url should check this variable to ensure
validity.
NOTE - There is a problem with Internet Explorer 5.0 and above regarding the HTTP_REFERER variable. When IE goes from an SSL encrypted page to a non-ssl encrypted page it neglects to set the variable, making it hard for you to use it in your security checking. We have produced a workaround which should take care of it. The workaround utilises the reply_link_url and return_link_url in conjunction. This method, although more complex than a simple referrer check, is more secure. That is not to say it is impossible to defeat but it is certainly harder!
Click here to download the scripts:
RETURN_LINK_URL SUPPLEMENTARY ARGUMENTS
The return_link_url is checked to see if it contains cgi arguments. If it does, it is disassembled and the names of all keys are checked against all keys listed in information_fields and a list of reserved fields (see below). Any matching keys have their values substituted for the runtime values of the variable. The return_link_url is then reassembled and substituted for the value passed to the script.
For Example:
If the order page contains
.....
<input type=text name="Name">
<input type=hidden name=information_fields value=Name">
.....
<input type=hidden name=return_link_url value="http://your.domain.com/cgi-bin/order.cgi?Name=">
.....
and the customer enters "John", then the return link url on the receipt page will contain
http://your.domain.com/cgi-bin/order.cgi?Name=John
and this can be handled by the script order.cgi.
Certain reserved fields are also specifically excluded from substitution and if they are requested, will be returned with null values. (see below for a list of excluded values).
The available field names (keys) are listed here:
- all information_fields (vendor defined)
(Information_fields may not contain reserved or prohibited
field names. If it does, their values will be ignored
and the internally generated values used. Unless contained
in the list of allowed return field names here, no value
will be returned via the return_link_url.)
- vendor_name
- payment_number
- currency (vendor defined)
- payment_status
- payment_group
- payment_date (epoch time)
- payment_reference (vendor defined)
- remote_ip
- settlement_date
- bank_reference
- summary_code
- response_code
- response_text
- response_amount
Although the runtime values of these fields will be supplied upon request, a number have no significance at this time. The purpose of each of these fields is explained later on this page.
For security reasons, the following field names have been specifically excluded and will be returned with null values.
- card_number
- card_type
- card_holder
- card_expiry
- card_expiry_month
- card_expiry_year
NOTES:
1. If any variable substitution is done, the return_link_url
is also varied to explicitly name the port used. The entire
parameter list is also converted to cgi encoding and ALL
non alpha-numeric characters are changed to the %hh format
where hh is the hexadecimal code for the character. Thus,
for a vendor called "greatcircle", a return_link_url of:
http://www.greatcircle.net.au/cgi-bin/subcribe.pl?vendor_name=no_such
becomes:
http://www.greatcircle.net.au:80/cgi-bin/subscribe.pl?vendor%5fname=greatcircle
noting also the substitution of "%5f" in place of "_".
If no substitution is required, either because the return_link_url
contains no arguments, or the arguments do not match any of
the appropriate field names, the return_link_url is not altered
in any way.
Special fields descriptions
vendor_name
This is the actual vendor_name of the vendor performing the
transaction. This field may be used as a substitute for
the PATH_INFO check included with the referring page.
payment_number
This is the unique number generated by the directOne server
to identify this payment for this vendor. It is listed in
the notification email and is used for retrieval of payments.
currency (vendor defined)
This is the currency notation used to describe the amount
of the transaction. All transactions performed using
directOne Platinum are done in Australian Dollars REGARDLESS
of what this field is set to.
payment_status
This field is used internally to identify a payment as "CURRENT",
"RETRIEVED" or "DELETED". As all new payments are "CURRENT",
the value of this field will always be the same at runtime. This
field is included here for completeness only and is not expected
to be any use to vendors.
payment_group
This field is used internally to identify a payment as "NEW" or "OLD".
It will probably not be particularly useful for vendors at this
time as ALL payments are given a value of "NEW" until they are
retrieved. Thus ALL payments will provide a value of "NEW" for
this variable. Although the groups may be expanded in future, for
the time being this field can be ignored, and is included here
for completeness only.
payment_date (epoch time)
This is the "date" of the payment measured in seconds since
January 1, 1970. Most programming systems should have a way of
converting this time to a more readable format.
payment_reference (vendor defined)
This is the reserved field which can be specified by the vendor
on their order page and is subsequently passed through and
recorded unchanged.
remote_ip
This is the IP address of the customer's computer (or proxy)
settlement_date (directOne Platinum only)
This is the date used by the bank to determine which "day"
the transaction occurred. Due to the bank's internal procedures
it may or may not be the actual date, but will only be one day
different at most. It is a four digit string representing
month and day.
bank_reference (directOne Platinum only)
This is a six digit reference number issued by the bank upon
completion of a successful transaction. It is unique for
this merchant on this day (as defined by settlement_date)
summary_code (directOne Platinum only)
Although this code can be one of four different values, only
one of these values will ever be avavilable to vendors through
the return link because the return link is only presented
for successful transactions. This is represented by a summary
code of "0". For this reason, this number is unlikely to be
of any practical use. It is included for completeness only.
response_code (directOne Platinum only)
This is an AS 2805.2 response code generated by the bank to
identify the outcome of a transaction. For the same reason
as given above (summary_code) it is unlikely to be of much
practical use, as it is almost always "08" for a successful
transaction. The one minor exception is an AMEX transaction
which will return "00" for success. It is included for
completeness only.
response_text (directOne Platinum only)
This is the textual description corresponding to the AS 2805.2
code returned in response_code. For the same reasons, it is
unlikely to be much use to vendors. It is included for
completeness only.
response_amount (directOne Platinum only)
This is the amount (in cents) that was approved for the
transaction. It may be used to verify the transaction amount
was as expected or to check against bank statements.