That's what we've been working with. It's also a unique feature of the encoded string as a "." isn't a BASE64 character. You should check for the presence of the 2 "."s as you need them in order to break up the received string into the 3 component parts.
I would suggest that you have a read through the start of the Serial Input Basics tutorial here:
I know it's aimed at receiving characters from a serial port, but swap "serial port" for "BLE port" and the mechanics of receiving the bytes are the same.
You should look at example 2 as I think that would best fit your scenario, but in your case, the recvWithEndMarker function would be using the NULL char as the terminator.
Off the top of my head, I don't think it would be wise to try and use example 3 with the recvWithStartEndMarkers as although you have a unique end marker - the NULL, you don't have a unique start marker. I would imagine that it's possible for the letter pair "ey" to appear elsewhere in the character stream besides the initial 2 characters.
EDIT: With BASE64, e = 30 => 011110 and y=50 => 110010.
Putting them together along with 2 unknown 6-bit chars, you get:
01111011 0010xxxx xxxxxxxx
01111011 => 0x7B = ASCII code for "{"
0010xxxx can be any value between 01000000 (0x20) and 00101111 (0x2F) which is any ASCII character from SPC to "/"