processRegistration

Accepts an XML document describing a primary registration_document and zero or more secondary registrations and processes the registrations.

Client Servlet Server Servlet HTTP Methods Supported Requires Authentication
CRTeamraiserAPI SRTeamraiserAPI POST Server.

Client API Syntax

https://secure2.convio.net/organization/site/CRTeamraiserAPI?method=processRegistration &api_key=value &v=value [ &center_id=value ] [ &error_redirect=value ] [ &redirect=value ] [ &response_format=xml | json ] [ &sign_redirects=value ] [ &source=value ] [ &sub_source=value ] [ &success_redirect=value ] [ &suppress_response_codes=value ] &registration_document=value [ &match_by_username=value ] [ &suppress_registration_autoresponders=value ] [ &update_constituent_profile=value ]

Server API Syntax

https://secure2.convio.net/organization/site/SRTeamraiserAPI?method=processRegistration & api_key =value & login_name =value & login_password =value & v =value [ & center_id =value ] [ & response_format =xml |json ] [ & source =value ] [ & sub_source =value ] [ & suppress_response_codes =value ] & registration_document =value [ & match_by_username =value ] [ & suppress_registration_autoresponders =value ] [ & update_constituent_profile =value ] [ & recordOnly =value ]

Usage Notes

Request Document

This method accepts an XML document with data for one primary TeamRaiser event registration, and if multiple registrations are allowed, one or more secondary registrations in the same event. The XML document follows the same format as the return document of getRegistrationDocument: 

			
<processRegistrationRequest xsi:schemaLocation="http://convio.com/crm/v1.0 http://service.convio.net/xmlschema/crm.public.v1.xsd" xmlns="http://convio.com/crm/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<eventId>1000</eventId>
	<primaryRegistration>
		<partTypeId>1100</partTypeId>
		<consId xsi:nil="true"/>
		<email required="true"/>
		<firstName required="true"/>
		<lastName required="true"/>
		<question>
			<id>1010</id>
			<type>PARTICIPATION_TYPE</type>
			<response xsi:nil="true"/>
			<key>T_SHIRT_SIZE</key>
			<hidden>false</hidden>
			<questionRequired>true</questionRequired>
		</question>
	</primaryRegistration>
	<secondaryRegistration>
		<partTypeId>1100</partTypeId>
		<consId xsi:nil="true"/>
		<email required="true"/>
		<firstName required="true"/>
		<lastName required="true"/>
		<question>
			<id>1010</id>
			<type>EVENT</type>
			<response xsi:nil="true"/>
			<key>Turned_In_Permission_Slip</key>
			<hidden>true</hidden>
			<questionRequired>true</questionRequired>
		</question>
	</secondaryRegistration>
</processRegistrationRequest>

See getRegistrationDocument for a complete example and more information about the request document.

Constituent Matching

When processing the primary registration, the method will attempt to find an existing constituent that matches the data in the request document. In order, the matching steps are:
  1. If <consId> is specified, the constituent with that constituent ID is used. If there is not a constituent with that ID an error will be returned.
  2. If <memberId> is specified, the constituent with that member ID is used. If there is not a constituent with that ID an error will be returned.
  3. If <username> is specified, the constituent with that username is used.
  4. If <email>, <firstName> and <lastName> are specified, the constituent with that email address, first name and last name is used. If more than one constituent matches, an error returns.
  5. If a matching constituent is not found, create a new constituent.

Team Matching

When processing the primary registration, the method attempts to find or create a team that matches the data in the request document if any of the following fields are included. In order of precedence:
  1. If <teamId> is specified, the team with that ID is used. If no team has that ID, an error is returned.
  2. If <previousTeamId> is specified, the previous team with that ID is reformed. If no previous team with that ID is eligible to be reformed by the primary registrant, an error is returned.
  3. If <teamName> is specified, a team with that name is joined. If no team exists with that name, a new team with that name is created, if possible.

Autoresponder Suppression

If the parameter suppress_registration_autoresponders is set to true the following autoresponders will not be sent to primary or secondary registrants:
  • Thanks for Creating an Account with Site
  • Thanks for Registering
  • Thanks for Forming a Team
  • Sample Solicitation

Payment Information

If you call this method via the Client API, you can:

  • Specify CREDIT_CARD in the <paymentType> element and pass credit card information for processing
  • Specify CASH or CHECK in the <paymentType> element to record a cash or check transaction
If you call this method via the Server API, you can record CASH or CHECK payment type transactions. To record a CREDIT_CARD payment type transaction, you must include the <recordOnly> parameter. Set the <recordOnly> parameter to true when you want to record a credit card transaction without processing the card and pass a bowdlerized credit card number where all digits except the last four are replaced with asterisks. If the <recordOnly> parameter is set to false and the payment type is set to CREDIT_CARD, the registration will be rejected with an error.

Note: If the selected event and participation type combination does not currently accept registrations, this method returns an error. This method can return an error even after the getRegistrationDocument method succeeds if another registration causes an event or participation type limit to be reached between the two calls.

Note: This method cannot be used to submit a registration to which a CAPTCHA question has been added.

Client API Parameters

Common Client Parameters

See topic Common Parameters.

registration_document

Required. The XML document containing the data for the primary registration and any secondary registrations.

Type xsd:string.

Default is .

match_by_username

Optional. If set to true, an existing constituent that matches the username provided in the registration document will be registered for the event.

Type xsd:boolean.

Default is false.

suppress_registration_autoresponders

Optional. Prevent autoresponders from being sent to the constituent(s) being registered.

Type xsd:boolean.

Default is false.

update_constituent_profile

Optional. If set to true and an existing constituent is matched for the primary registrant, the constituent profile will be updated. Secondary registrant information is never used for updates. It is only used for creating new constituents.

Type xsd:boolean.

Default is false.

Server API Parameters

Common Server Parameters

See topic Common Parameters.

match_by_username

Optional. If set to true, an existing constituent that matches the username provided in the registration document will be registered for the event.

Type xsd:boolean.

Default is false.

recordOnly

Optional. When set to true, administrators can record a TeamRaiser registration with a payment type of CREDIT_CARD, but the credit card is not charged. To use this parameter, the administrator must pass a bowdlerized version of the credit card number where all digits except the last four are replaced with asterisks. This security feature allows a Server API call to maintain PCI compliance while recording CREDIT_CARD transactions. This parameter cannot be used in Client API calls.

Type xsd:boolean.

Default is false.

registration_document

Required. The XML document containing the data for the primary registration and any secondary registrations.

Type xsd:string.

Default is .

suppress_registration_autoresponders

Optional. Prevent autoresponders from being sent to the constituent(s) being registered.

Type xsd:boolean.

Default is false.

update_constituent_profile

Optional. If set to true and an existing constituent is matched for the primary registrant, the constituent profile will be updated. Secondary registrant information is never used for updates. It is only used for creating new constituents.

Type xsd:boolean.

Default is false.

Response

See topic HTTP Status Codes.

XML response 
<?xml version="1.0" encoding="UTF-8"?>
<processRegistrationResponse xsi:schemaLocation="http://convio.com/crm/v1.0 http://service.convio.net/xmlschema/crm.public.v1.xsd" xmlns="http://convio.com/crm/v1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <transactionId>1325</transactionId>
  <confirmationCode>1-1001-20-1001-1001</confirmationCode>
  <primaryRegistration>
    <registrationId>1001</registrationId>
    <consId>1100000</consId>
  </primaryRegistration>
  <secondaryRegistration>
    <registrationId>1002</registrationId>
    <consId>1100001</consId>
  </secondaryRegistration>
  <secondaryRegistration>
    <registrationId>1003</registrationId>
    <consId>1100002</consId>
  </secondaryRegistration>
</processRegistrationResponse>
JSON response 
{"processRegistrationResponse":{"secondaryRegistration":[{"consId":"1100001","registrationId":"1002"},{"consId":"1100002","registrationId":"1003"}],"transactionId":"1325","primaryRegistration":{"consId":"1100000","registrationId":"1001"},"confirmationCode":"1-1001-20-1001-1001"}}
Parent topic: TeamRaiser API
Previous topic: previewMessage
Next topic: removeCompanyPhoto

Comments

Submitted by GPeck at 06:45 AM on May 1, 2013
Complete documentation of error responses is needed for this method. The PDF Documentation does a good job of outlining technical error codes, but does not include critical UI messages. For example, error codes 2677 and 2697 appear to be generic Credit Card Decline codes. There must be others, but testing failure path results in IP Blocking after more than a few planned errors.

Leave a Comment

Nickname
Comment
Enter this word:
Change