Returning a password is integral to verifying whether a user has successfully made a transaction. You can verify this by getting the user to provide you the password, then cross referencing it against the passwords you have sent to a user. Without performing this, there would be no 100% reliable way to successfully verify that the user has paid.

There are other less popular, more complex methods of delivering content without a password, for example if it is a software download / mp3 / video that you are selling, you could return back a direct link to the download, and to avoid end-users sharing that link, force the user to enter their mobile/cellphone number, allowing the download only once per mobile/cellphone number.

There are other methods that you could use, for example provide an email address in the return billed that they must email to receive the service they have paid for, however again whichever method you use without the Password verification, you must be sure that you can verify that they have paid.

Another option is to rely on delivery reports to trigger the delivery of goods. In theory this is a good, reliable method, however the networks / carriers can take 48 hours to pass a delivery report. This means that the user could be waiting round for a long time to receive their service, which leads to customer service problems.

A good work around if you are keen on using delivery reports for activation of a users service is to also use password verification using the password included in the outgoing billed MT. Process as follows:

1) MO with keyword

2) Trigger billed MT (include a unique password)

3) User hits the "verify me" button

4) Check for successful delivery report whilst displaying to the user a “verifying” page.

5) On a "verifying" page, or if "unsuccessful verification" display a password entry box and a note saying "If you received a message with a

password in it, enter here [          ]."

6) If successful delivery report, or if user enters password correctly activate account.