Payments

Last updated on
2 May 2018

Drupal 6 Ubercart

Ubercart 2 payments are considered historical, they are not intended for use after the migration. They are migrated to the manual payment gateway and hidden by default.

Details

In Ubercart 2, Drupal 6, the payment table is more like a log than anything else. It is a dedicated table with 1 row per payment. A payment can have a positive or negative value (refunds), and merely references a text value of the payment gateway. There is no attached functionality or relationships between a payment entry and the payment gateway.

In Commerce 2, Drupal 8,  a payment is directly associated to a payment gateway. There is one line per payment however refunds are associated to a specific payment. It is not possible for a single refund to have a higher value than that of a single payment. For example, you cannot have a 2 payments of 40€ totalling 80€ and associate 80€ of a refund to one of the payments. You would do a full refund of the two entries. This is the big difference between Ubercart 2 and Commerce 2.

Firstly, in order to set up the payment entries in Commerce 2, we create manual payment gateways. This is handled in a separate migration, d6_ubercart_payment_gateway. Ubercart payment entries are associated with manual payment gateways, instead of a new payment gateway, for 2 reasons. One, we can’t guarantee that the module exists in Drupal 8 for the payment gateway used in the Drupal 6 source site, nor that it has a migration prepared. Second, in Commerce 2, refunds associated to a real payment gateway might trigger an actual refund of the money. Imagine doing a migration and actually triggering a refund of all the money you ever charged your customers. The payment gateways are set to manual mode and are set to not appear in the checkout by default.

The payment migration is fairly straight forward, for every payment line in Ubercart 2, we add a payment line in Commerce 2. The complication comes when there is a refund. The Ubercart migration destination plugin attempts to associate a refund to a previously migrated payment. This process is unconventional and not encouraged by the migrate team, but has been implemented for lack of a better solution. When the migration finds a refund, it will query the payments that have already been migrated for that order, find one that is larger than the refund value, and use that payment id as the destination for the refund instead of its own line.

Several things are assumed.
1. No order has a higher amount refunded than paid. This would have to be fixed manually.
2. No order has a refund before the first payment. This would have to be fixed manually.
3. No single refund is larger than all individual payments made. This would have to be fixed manually.

Help improve this page

Page status: No known problems

You can: