Two kinds of products and one order table

I'd question why you have OrdersForProductX tables at all
It's possible the FK problem you've asked about can be designed out...

If these tables have the same structure, then you simply need a ProductType column on some OrderProduct table. Then Payment just links to that with one FK

If the table have different structures, I assume they have some common attributes. So, you can have a common OrderProduct table then specific child table per product type (see below) Again, Payment just links to the commone table with one FK

This is the "superkey/subtype pattern"

• UQ1 is the "super key" used a foreign key on the subtype tables
• Each subtype table has a composite PK and FK on (OrderID, ProductType)
• Each subtype table has a CHECK constraint to restrict types in that table

OrderProduct

• OrderID, PK, UQ1
• ProductType, UQ1
• CommonThing1
• ...

OrderProductA

• OrderID, PK, FK
• ProductType, PK, FK, CHECK ProductType = A
• ProductAThing1
• ...

OrderProductB

• OrderID, PK, FK
• ProductType, PK, FK, CHECK ProductType = B
• ProductBThing1
• ...

Not enough time to test or write out all of the table creation but this is a start...

First create the table to hold the users. You can get data from the following query. One thing I don't know how you want to handle is if a user exists with a different phone number.

SELECT DISTINCT name
  , phone
FROM old_table

After you have the user_accounts table join it back to the old_table to get the address along with the new user id.

SELECT DISTINCT a.address
  , b.id
FROM old_table a
INNER JOIN user_accounts b on a.name = b.name and a.phone = b.phone