How to send a USSD code containing decimal floating point (.)?

Question

I need to send a USSD code containing a double value, that represents the balance account amount to be transferred. This value is composed by an integer number, and optionally a decimal separator and 2 more digits. My code looks as follows:

    double doubleValue = 0.70;
    String phoneNumber = "51234567", pincode = "1234";
    String ast = Uri.encode("*");
    String baseUssd = ast + "234" + ast + "1" + ast + phoneNumber + ast + pincode + ast;
    StringBuilder builder = new StringBuilder();
    builder.append(baseUssd);
    builder.append(doubleValue); //i.e: 1.35, 0.80
    builder.append(Uri.encode("#"));
    Intent intent = new Intent(Intent.ACTION_CALL, Uri.parse("tel:" + builder.toString()));
    startActivity(intent);

My phone treats the doubleValue as 135, 080, etc. ignoring the dot separator character. I hope the final code includes "dot", allowing send the decimal value. Someone solved this problem?

Photocell

Tomorrow I will start a bounty here, but I think that you must add more code like the vars doubleValue and pincode, this can help other user to found the answer – Venturous

you got some advance? – Venturous

No, I don't. These two answer's approach are well, but none of them solves the problem. The second sends myself possibly to dialogue with Etecsa, but... it is only a possibility – Photocell

Answer 1

The Java code shown works fine of course assuming that doubleValue is a float or a double.

As suggested here the Intent is handled by OutgoingCallBroadcaster.processIntent() which processes the String given in the Intent by calling PhoneNumberUtils.convertKeypadLettersToDigits() and PhoneNumberUtils.stripSeparators().

The latter one strips everything except numbers, *, #, + and the WILD, WAIT and PAUSE symbols.

This is where your decimal separator is lost.

So either the separator should be escaped to a specific numerical value or substituted by one of the accepted symbols to actually leave your phone and reach the receiver.

Whoever is responsible for the receiving end can probably advice you on properly formatting your decimal number.

Sergias

Thanks Markus. I can't tell if the "receiver" answer me, I could try anyway. Can I replace the OutgoingCallBroadcaster by my own? – Photocell

I don't think that replacing OutgoingCallBroadcaster is realistic. But if you look at the comments in link it's said that it will receive the CALL intent (from your application) and after doing what it does it broadcasts an ACTION_NEW_OUTGOING_CALL intent. You could apparently receive the the ACTION_NEW_OUTGOING_CALL intent with a BroadCastReceiver and still change the intent details including the phone number that includes your USSD command. – Sergias

See e.g. this for an example of receiving the outgoing call intent. See this blog post for example code of actually modifying the phone number inside the intent. So looks like there's a chance that you could intercept the outgoing call and put the decimal separator back where it belongs unless it's just against some ITU standards and whatnot and still gets stripped later on in the process. – Sergias

Answer 2

Thinking about the way the pinpad, which my bank sent me, works, you always have to enter the two digits after the decimal point and the formatting on the display deals with the position of the point.

So if i enter "1", it is interpreted as 0.01. Similarly "1023" would be 10.23.

I think the same approach could work nicely for you. So 1.23 is entered as "123" and 0.80 as "80"

I can't see a reference that limits the characters to 0-9#* but all the examples follow this format. However, your example starts *234, which seems to fit this rule in the specification

Case a) 1, 2 or 3 digits from the set (*, #) followed by 1X(Y), where X=any number 0-4, Y=any number 0-9, then, optionally "* followed by any number of any characters", and concluding with # SEND: This case is reserved for HPLMN use. When a serving network receives such a message from a visiting subscriber, it shall pass the USSD message directly to the HPLMN. If it receives it from a home subscriber, it is up to the network to decide whether to treat it locally or to pass it to the HLR

http://www.etsi.org/deliver/etsi_ts/100600_100699/100625/07.00.00_60/ts_100625v070000p.pdf

In general, I am not sure the HPLMN (Home Public Land Mobile Network) or HLR (Home Location Register) would expect the extra characters, even though the whole character set and even other character sets are allowed in the USSD protocol.

Crime

Just wondering whether you have tried encoding the decimal point with Uri.encode(".")? – Crime