Data types would help. I'll assume id is an int data type. I'll also assume SQL Server as the dbms but these points are valid for other dbmses as well. [My first major programming job was in an Order Entry, Shipping and Credits system, so I'm very familiar with related data structures.]
If payment is just the main method that customer uses to pay, it should be in the CUST table. If it's payment(s) for a specific order, it/they should be in an ORDER_PAYMENTS table. There can be multiple payments and/or credits/adjustments, etc., for a single order.
The ORDER_DETAILS key should not be just ( id ) but rather ( order_id, id ). This will cluster the details rows by parent key first and the SQL engine will "know" they are clustered that way. ( * )
Personally I think street addresses should always be stored in a separate table, for efficiency and for ease of scrubbing the data. Thus, the ORDERS table would have a shipping_address_id rather than the entire address. Since a given customer tends to ship to the same address over and over, this can cut down a lot on storage, while making data easier to scrub. This approach also makes it easy to pull up all the addresses used by a single customer.
( * ) I'm a DBA, trust me on this one. Best clustering will allow an extremely efficient MERGE join between the tables, even if a lot of orders are being joined. Btw, the "default" approach of automatically clustering every table on an id column is terrible overall for performance. It's the most damaging myth in physical db design. The clustering key is the single most important factor for table performance. Thus, it should always be chosen based on specific table structure and usage, not on an extremely generic (supposed) "rule".