Collegiate Golf Alliance
The following represent the Collegiate Golf
Alliance's (CGA) policies pertaining to customer data and financial
The CGA will not share any customer data
without the customer's express opt-in approval to do so. The CGA will
not contact its members with advertisements or special offers without their
express approval to do so. During the customer account creation
process -- and at any time thereafter -- customers may choose the degree to
which their personal information is used by the CGA. There are four
levels of opt-in data usage and communication that a customer may choose:
- No data sharing or communication from
CGA or its partners
- Receive email updates from CGA
regarding events hosted by the member's affiliated universities
- Receive general e-mail updates and
special offers from the CGA
- Receive e-mail updates and special
offers from the CGA's partner companies
Any funds collected online by the CGA
are sent directly to the Tournament Director. Therefore, in the
circumstance that an event is cancelled or a player decides he no longer
wants to play, all requests for refunds must be made to the Tournament
Director, not the Collegiate Golf Alliance. As such, refunds are
at the sole discretion of the Tournament Director pursuant to the
event's refund and cancellation policy.
The CGA is not responsible in any manner for refunding registration fees
to individual event participants.
Credit Card Data
All credit card
transactions initiated on the CGA website are secured using encryption
technology. The Simple Integration Method (SIM) improves the
WebLink and Relay Response connection methods by using a script to
encrypt transaction information.
Using SIM, a transaction is initiated in the following way:
1. The merchant
retrieves a transaction key from the Merchant Interface. (The
transaction key is similar to a password and is used by the system to
generate a transaction fingerprint.
merchant creates an HTML page that either includes an embedded script or
points to a script that has been installed on the merchantís Web server.
3. The script, whether
on a server or embedded in the HTML page itself, generates the unique
fingerprint (using the transaction key) and submits it to the gateway
with the transaction information.
4. The fingerprint is
used by the gateway to authenticate that the transaction originated from
an authorized merchant. If the transaction is authenticated, it is then
submitted for authorization. If the transaction cannot be authenticated
by the system using the fingerprint, it is rejected.
If you have any questions about these
policies, please contact the CGA at