All of the information provided by Bitcoin Core applies only to the chain it currently thinks is the best block chain. Any blocks which are not part of that chain are not counted towards the confirmation score.

If you're using Bitcoin Core in a merchant application, you should probably test what happens during various-length forks. You can do this using the regression test (regtest) mode. For example (I haven't tested this):

nodeA_options="-regtest -rpcpassword=foo"
nodeB_options="-regtest -rpcpassword=foo -datadir=/tmp/regtest -port=9999 -rpcport=10000"

## start node A
bitcoind -daemon $nodeA_options

## Create a block to get its coinbase in your wallet (unspendable for 100 blocks)
bitcoin-cli $nodeA_options setgenerate true 1

## start node B and connect it to node A; it'll sync the block
bitcoind -daemon $nodeB_options -connect=localhost

## stop node A to break the connection
bitcoin-cli $nodeA_options stop

## generate a block on node B
bitcoin-cli $nodeB_options setgenerate true 1

## Restart node A and generate a block
bitcoind -daemon $nodeA_options
bitcoin-cli $nodeA_options setgenerate true 1

## Stop and restart node B with a connection to node A
## At this point, both nodes have a different block #2 so you can see
##   what a fork looks like to the nodes
bitcoin-cli $nodeB_options stop
bitcoind -daemon $nodeB_options -connect=localhost

Of particular use, you will probably want to set the -alertnotify command, which can warn you about longer forks and allow you to automatically shutdown your payment processing system until the fork is resolved or you intervene manually. You may also want to look at the listsinceblock RPC which can work in conjunction with -blocknotify to tell you what's changed in the most recently-accepted block.