There is no such thing as "as secure as AES" when it comes to encryption. This sounds weird, but let me explain. AES is a block cipher. As block cipher it always uses deterministic permutation of the bits in the plain text block. And as it is deterministic it always encrypts the same plaintext block to the same ciphertext block.
It is therefore not IND_CPA secure when used as a cipher. In other words, you can clearly see that the same plaintext encrypts to the same ciphertext; you can therefore distinguish plaintext blocks by looking at the ciphertext blocks. AES is a secure block cipher, it is not a secure cipher by itself.
Now if you would add padding bits then you would still not accomplish IND_CPA security. Padding schemes for block ciphers - such as PKCS#7 padding - are generally deterministic. So that's not going to work in the general case.
CTR mode encryption is considered a secure mode of operation for block ciphers with a block size of 128 bit or more. CTR mode however requires a nonce to operate. So you would either have to generate one and store it with your ciphertext or you would have to use some out-of-band means to generate a nonce (e.g. a number stored elsewhere in a database). This is a good option if you can store some 128 bits of output: simply store a 64 bit randomly generated nonce and 64 bits of ciphertext (which you may have to extend to 128 bits for many API's by right-padding with zero's).
CTR mode doesn't add any integrity protection, so you might want to add this by using an authenticated (AEAD) cipher. This will however add more bits for the authentication tag to the output.
With 64 bits of plaintext it becomes very tempting to simply encrypt with a 64 bit block cipher. This won't provide IND_CPA security, but you may not care if identical plaintext blocks can be distinguished. You could also take a look at Format Preserving Encryption. Triple DES would still be an option for this; in practice it will likely offer as much security as a 128 bit cipher.
Maybe it's a good idea to use public key encryption. This would for instance be the case if you don't want the decryption key exposed during encryption.
I've answered this in the general sense. But you can see that there are many unknowns to us. This is why the question "Is there any other scheme that i can use to encrypt 64 bit data and is as secure as AES." is bunk.
Encryption is not a goal; providing security for your data is. And without a clear definition of your goals, use cases, requirements and threat models any answer may be wrong.
Note that all schemes have limits on how many 64 bit blocks may be encrypted with a single key.