Knowledge Base » Charge to Account Gateway (including Payforit)

• Knowledge Base
  • General
  • SMS Gateway
  • MMS Gateway
  • Charge to Account Gateway (including Payforit)
    • Payforit
    • Subscriptions

Contents

• Why is the Charge To Account Gateway returning a userinputrequired error? [38]
• What are the differences between a test CTA account and a live CTA account? [39]
• Why is the end user receiving an unexpected 'account cannot be detected' error? [40]
• How can I prevent a user buying the same product or service twice without forcing them to log in? [43]

Why is the Charge To Account Gateway returning a userinputrequired error? [38]

When you make a valid charge or subscription request, you will usually receive a response similar to this:

outcome:userinputrequired

outcomeReasonId:2002

outcomeReasonText:Missing information that requires user input.

redirectUrl: ...

transactionId: ...

This is not an error. This response means that the end user must visit the URL specified by the redirectUrl parameter.

This enables the Charge To Account Gateway to verify the mobile account to charge.

Your application should redirect the end user's mobile browser to the specified URL. This is most commonly implemented as an HTTP redirect.

What are the differences between a test CTA account and a live CTA account? [39]

Test accounts are available for evaluating the Charge To Account Gateway API.

Note that while using a test account:

• no charges are actioned.

• the value of the msisdn parameters returned in a notification is always TESTMSISDN rather than the true mobile number; similarly, the uniqueUserIdentifier value returned is always an identifier for TESTMSISDN.

• no age verification is carried out for transactions, subscription setup or AUID requests.

• you can confirm a charge using any browser, whereas with a live account, the charge must be confirmed from a phone's WAP/XHTML browser to allow the gateway to detect the mobile number.

• charges of any value are accepted, wheareas with a live account, you must ensure that any charge value you wish to use is provisioned to your account beforehand.

Why is the end user receiving an unexpected 'account cannot be detected' error? [40]

If the end user's mobile number (MSISDN) cannot be detected when they visit the payment verification page hosted by the Charge To Account Gateway, the following error will be displayed:

"We cannot bill your mobile account as either your mobile account cannot be detected (this may be caused by certain WAP/mobile browsers including Opera-Mini) or your mobile network is unsupported. If you are using Opera-Mini then please try again using a different mobile browser."

Possible causes to eliminate include:

1. The end user is not on a supported mobile network (currently only the major UK networks and some US networks are supported).

2. The end user is not using the handset's default browser (for example, it is not possible for the gateway to detect the MSISDN if the browser is Opera Mini).

3. The handset is connecting to the gateway through an Internet APN rather than a WAP APN.

3. The handset is connecting to the gateway using Wi-Fi, rather than GPRS or 3G.

4. The value of the requested charge has not been provisioned to your Charge To Account Gateway account. Only certain charge values are supported. Ensure that all the charges you attempt are supported by the destination network.

How can I prevent a user buying the same product or service twice without forcing them to log in? [43]

The Charge To Account Gateway does not maintain a list of unique product identifiers, so it has no way to prevent an end user who has already purchased a product or service from buying the same item again.

However, your application can handle this situation by using the gateway's Anonymous User Identification (AUID) API to retrieve the purchase history of visitors.

For example, suppose you use the Charge To Account Gateway to offer subscription services from a WAP/XHTML site.

1. A user visits your site and subscribes to your "Service A".

2. When the subscription request succeeds, your application stores the uniqueUserIdentifier and subscriptionId returned by the gateway, linked to your unique product identifier for "Service A".

3. Later, the user returns to the sign-up page on your WAP/XHTML site for "Service A" and mistakenly attempts to subscribe a second time.

4. Before making a subscription request to the gateway, your application uses the Anonymous User Identification API to retrieve information about the visitor.

5. Among other information, the AUID request returns the user's uniqueUserIdentifier and the subscriptionId of any active subscriptions: in this case, the subscription to "Service A".

6. Your application can now determine that the user has already subscribed to the service, and prevent a duplicate subscription.

See the Anonymous User ID documentation for details.