If B specifically wants the data encrypted end-to-end from the field device to them, then indeed you need devices injected under a BDK known to B -- either you generated and gave to B, or B generated itself and gave to you or your vendor(s)/injection facility(s) -- and preferably not used by or shared with anybody else.
You don't say what type(s) of devices and users/settings you are concerned with. I have seen (in the US) some retail/point-of-sale (magstripe "swipe" and pinpad, sometimes EMV) devices that can be injected with two device keys, under two different BDKs. But the ones I saw tended to be the higher end (thus more expensive), and you still have the problem of choosing which key to use for a given transaction/data-item, which usually means some other system that is interfacing with the human(s) involved, like a cash register/till, being modified to make this decision and command the device.
If B is only concerned about the data being encrypted all the time so it isn't vulnerable to attacks, they might well be satisified to treat your server as a single (unusually busy) device in their network -- i.e. they assign you an initial key (and corresponding initial KSN) under their BDK; you get each transaction encrypted by the device under a BDK-A key, decrypt it and immediately re-encrypt it under the BDK-B key, and send it up to B.
If you are using an HSM for your crypto, and for large volumes of payment-sensitive data you should, this is often provided as a single operation called "translate" -- that is, instead of "decrypt under key #3" then "encrypt under key #17", your software can request "translate from key #3 to key #17", and then the plaintext is never visible in your CPU/memory/swap, only within the dedicated and hardware-protected HSM.
Depending on your transaction volumes this could burn through the somewhat-less-than-2^21 values of TCTR pretty fast, so B may have to send you another "device" key (or maybe several) every month, or week or whatever, using some mechanism that is both secure and as automated as possible to avoid mistakes. You should definitely try to have each new key ready at least a week before you expect to need it, preferably more, in case volume spikes or some fault forces you to switch early. But if they're making money on the transactions you send them, and they presumably wouldn't accept your business otherwise, they should be able to manage.