user26697: I would like to generate a bitcoin paper testnet wallet.
A paper wallet is a QR code of a private key and a QR code of a bitcoin testnet address, I assume it can be generate juste like this link does : https://api.qrserver.com/v1/create-qr-code/?size=150x150&data=privateKeyOrBtcAddress
But when I'm trying to read it via Testnet3 android app, funds are not recognized. When I read the QR Code from a QR Reader app, I see correctly the content (privateKey for instance).Should I conclude that the application has a problem with this feature or did I miss something ?

user10377: Here is an example of taking a 256-bit hex-encoded private key and creating an uncompressed Wallet Input Format (WIF) private key for testnet using the libbitcoin v3.0 bitcoin-explorer (bx) command line interface. bx sub-commands manual pages are located on the right column of its Wiki
% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx base58check-encode -v 239
91avAoeY5k21BDnfaHNLv63frRJhn5RmnEw4XgcsbfpWxPg1A9N
Similarly, here are the results for the associated  compressed public key.  (Note by convention that "01" is tucked on to the private key.)
echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff01" | bx base58check-encode -v 239
cMahgGtgBvsRn7SZFuFCuKGnV8H8yxYLegVcaRsLL2LjD6WFLuAg
More details for using bx for altcoins can be found at Altcoin Version Mapping.  There is a table up top of the wiki that provides insight as to why 239 and 111 are used as versions in bx commands above and below.
Use what ever QR-encoding mechanism you like (e.g., QRencode and encode either 91avAoeY5k21BDnfaHNLv63frRJhn5RmnEw4XgcsbfpWxPg1A9N or cMahgGtgBvsRn7SZFuFCuKGnV8H8yxYLegVcaRsLL2LjD6WFLuAg, but remember the following 256-bit hex encoded private key
0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff 
is one of the worst private keys ever... but makes the point real clear we have a 256-bit hex-encoded key.
Be aware if the funds are deposited to an uncompressed public address and you provide the private WIF key for a compressed address an import or sweep is not likely to work.
The uncompressed public address for the very simple private key can be found by:
% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public -u | bx ec-to-address -v 111
n2nkn4KFNtNbu6Q6GQPZwNZWDiiNsmm9d8
Similarly, the compressed public address can be found by:
% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public | bx ec-to-address -v 111
n47QBape2PcisN2mkHR2YnhqoBr56iPhJh

26697: <p>I would like to generate a bitcoin paper testnet wallet.<br>
A paper wallet is a QR code of a private key and a QR code of a bitcoin testnet address, <br>I assume it can be generate juste like this link does : <a href="https://api.qrserver.com/v1/create-qr-code/?size=150x150&amp;data=privateKeyOrBtcAddress" rel="nofollow">https://api.qrserver.com/v1/create-qr-code/?size=150x150&amp;data=privateKeyOrBtcAddress</a></p>

<p>But when I'm trying to read it via Testnet3 android app, funds are not recognized. <br>When I read the QR Code from a QR Reader app, I see correctly the content (privateKey for instance).<br>Should I conclude that the application has a problem with this feature or did I miss something ?</p>
 10377: <p>Here is an example of taking a 256-bit hex-encoded private key and creating an uncompressed Wallet Input Format (WIF) private key for testnet using the libbitcoin v3.0 bitcoin-explorer (bx) command line interface. bx sub-commands manual pages are located on the right column of its <a href="https://github.com/libbitcoin/libbitcoin-explorer/wiki" rel="nofollow">Wiki</a></p>

<p><code>% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx base58check-encode -v 239</code></p>

<p><strong>91avAoeY5k21BDnfaHNLv63frRJhn5RmnEw4XgcsbfpWxPg1A9N</strong></p>

<p>Similarly, here are the results for the associated  compressed public key.  (Note by convention that "01" is tucked on to the private key.)</p>

<p><code>echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff01" | bx base58check-encode -v 239</code></p>

<p><strong>cMahgGtgBvsRn7SZFuFCuKGnV8H8yxYLegVcaRsLL2LjD6WFLuAg</strong></p>

<p>More details for using bx for altcoins can be found at <a href="https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings" rel="nofollow">Altcoin Version Mapping</a>.  There is a table up top of the wiki that provides insight as to why 239 and 111 are used as versions in bx commands above and below.</p>

<p>Use what ever QR-encoding mechanism you like (e.g., <a href="https://github.com/fukuchi/libqrencode" rel="nofollow">QRencode</a> and encode either <strong>91avAoeY5k21BDnfaHNLv63frRJhn5RmnEw4XgcsbfpWxPg1A9N</strong> or <strong>cMahgGtgBvsRn7SZFuFCuKGnV8H8yxYLegVcaRsLL2LjD6WFLuAg</strong>, but remember the following 256-bit hex encoded private key</p>

<p><strong>0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff</strong> </p>

<p>is one of the worst private keys ever... but makes the point real clear we have a 256-bit hex-encoded key.</p>

<p>Be aware if the funds are deposited to an uncompressed public address and you provide the private WIF key for a compressed address an import or sweep is not likely to work.</p>

<p>The uncompressed public address for the very simple private key can be found by:</p>

<p><code>% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public -u | bx ec-to-address -v 111</code></p>

<p><strong>n2nkn4KFNtNbu6Q6GQPZwNZWDiiNsmm9d8</strong></p>

<p>Similarly, the compressed public address can be found by:</p>

<p><code>% echo "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | bx ec-to-public | bx ec-to-address -v 111</code></p>

<p><strong>n47QBape2PcisN2mkHR2YnhqoBr56iPhJh</strong></p>
