I'm using PayPal's PayPalAPIInterfaceService and I see that I can pass TransactionSearch a Payment Profile ID and it will pull back all Payment Transactions but is there a way to take a Payment Transaction ID and get back the associated Payment Profile ID?
We're trying to reconcile monthly Transactions and while the Transaction records returned from TransactionSearch indicate they're Recurring Payments, they don't seem to give the assocaited Payment Profile ID.
If you are using IPN and having all the transaction information written to your database, you could just query your own database for this information. If you are not using IPN, you could set it up and use it for transactions and profiles going forward.
Related
Assume a database holds some accounts and its transactions.
There would be a table Account (for simplicity it holds only an id) and a table Transaction that has columns id, account_id (foreign key), type, and value.
Now, if some money gets deposited there is no problem. account_id is chosen and type and value are defined. But what if I want to transfer money from account a to account b?
I thought about adding some kind of offset_account_id to distinguish from where to where but this is not a good solution imo.
Or do I add two transactions for each of the involved accounts? Then I first have to insert both and after update both as they need to have a circular reference to each other.
Third I thought about adding a 'transfer' table that will hold the transaction_id of the involved accounts.
My problem with the last solution nonetheless is if I delete account a I want to cascade this throughout the database, all transactions should be deleted automatically. But if I delete a then the transaction for a will disappear and the entry in the transfer table as well but the transaction of account b would still be in the database.
What is a good layout for these 'accounting' problems?
Side question: would you calculate balance at runtime or work with on insert/delete/update triggers to store the balance with the corresponding account?
I am posting an example of the tables described above. In this example, the account ID "100" has made a payment of $30 to the account ID of "123". The transaction shows up as a record in the payable table and as a record in the receivable table.
Then if the account for 100 is closed one day, you would remove the remaining balance from the account by creating a new record in the accounts payable table. If the money is transferred to a new account then a record would also be created in the accounts receivable table. This will show the history of funds moving. If you are wanting to keep track of which accounts are open or closed I would also suggest creating a table that contains all account numbers, customer names, and a column for "open/closed". That way closed accounts will be reflected in your data and you can still query based on open or closed accounts, but the history will not be deleted, which is vital for good accounting records.
I tried looking at similar StackOverlow posts and it seems as those questions for input about schema is valid. Also, I'm a software developer and not a DB expert by trade. So hopefully this is met well.
I'm using SQL Server, though I think this question is generic enough that it might be applicable to pretty much any SQL product as it pertains to what's the best schema for my scenario.
I'm writing a referral payment system whereby stores may credit and pay back individuals who refer customers. The entities are -
Referrer: the one to be paid for referring customers,
Referral: the customer that was referred
Referral Purchase: The amount and date of the referral's purchase.
Admin: the one doing the paying.
When determining what to pay the referrer I need to tally up all of the referral purchases that have not been credited. The sum at the time of the pay out attempt is what gets paid.
The confounding part of this whole thing is that when an Admin makes a payment, it may fail for any number of reasons (insufficient funds, the referrer gave bad PayPal information, etc.). All of this needs to be stored so that I can not only look back over past payment attempts and determine the failures and what referral purchases were involved in the failure, but also to determine which referral purchases have yet to be credited to the referrer.
The best schema I've been able to devise is the following:
The point here is that each PaymentAttempt holds the status of the payment attempt (success/failure) and each Referral Purchase that was credited in the payment attempt has a link table which associates it with the payment attempt. One referral purchase may, then, be involved in any number of attempts to credit the referrer, with the last one being the successful attempt.
Ultimately my question comes down to this: when I need to go back and then determine how much the referrer needs to be paid at a later date, is it going to be a pain in years to come if I need to query ALL of the ReferralPurchases associated with the referrer, then join ALL of the ReferralPurchase/PaymentAttempt link tables, then join the associated PaymentAttempt status tables to find out which of the referral purchases have yet to be credited? I could see myself needing to create pretty weird queries just to find those five purchases that have yet to be credited.
Alternatively I could update the ReferralPurchase itself with a status flag, but is this considered "asking for it" in terms of data integrity (I think I could see some saying this is poor design since the state could be queried in other ways, and perhaps a bug might result in the bit being set without proper records to warrant it)? Is that bad design?
Or is there some better way to lay things out?
Will try my best to help you out, hopefully I understand your question correctly. If I were designing the system, there would be two tables that stand out for me. The tables and their columns are.
ReferralPurchase
• ReferralPurchase_Id (PK)
• Referrer_Id (Pointing to a person table)
• Referral _Id (Pointing to a person table)
Payment
• Payment_Id (PK)
• ReferralPurchase_Id (FK)
• AmountToBePaid
• StatusOfPayment
• DateLogged
• DatePaymentMade (Null if status is not successful)
• Admin_Id (Pointing to a person table)
Ben, not sure what you mean by status field. I would steer away from lifecycle status fields, but would consider a boolean. For example:
An isPaid flag on ReferralPurchase would seem like a reasonable approach. It should only be updated on a confirmed payment, and if there is a query on why it has been set, the evidence will exist in the form of history from the PaymentAttempt and link tables. This would simplify queries of outstanding payments, and pending payments would just be incomplete PaymentAttempts. There is the theoretical possibility that the history could contradict the value of the flag.
Alternatively, you could have an isSuccessful flag on the link table, which is "closer to source", if I can put it that way, in that it cannot as easily be in conflict, as it is the history itself (as long as the coder does not allow more than one row to be marked isSuccessful for a given ReferralPayment for example). Finding outstanding payments is just those ReferralPayments where not exists an isSuccessful link record.
Others will have different views on this. Let us know which way you go.
I'm looking into using a company that uses Yodlee's data aggregation service and have looked some sample output that includes account information and transactions. I noticed that the unique ID and account number for the account are not housed in the table containing transactions. How do people typically go about mapping transactions to a particular count when placing multiple accounts into a relational database? It seems to me that there is no field to link the table containing account information and transaction information together.
You can use the identifier called "itemAccountId" which is a Yodlee internal id tied to uniquely identify an account. This identifier is present for an account as well as each transactions. Using this id you can segregate the transactions under same account.
Please go through the sample responses of these two APIs getItemSummaryForItem1 and executeUserSearchRequest
Paymill: If I have created a subscription, will Paymill automatically create future transactions for me or do I have to manually create a transaction next month?
If it's automatic, how do I determine whether the transaction was successful or not?
Paymill automatically creates a transaction for each subscription/offer after the defined period of time (week/month/year). Each of these transactions has the subscription id in its description field so you can find them. The status of those transactions is indicating whether the transaction was successful or not.
There is a regular Users (UserID, UserName, Email, Password) table which handles user registrations.
Which other tables should be added in order to handle paid membership with 2 types of paid subscriptions - Monthly and Yearly.
I think you may want to distinguish between membership details and transactions. I like the idea of adding a membership_type column (should be a tinyint column with a separate lookup table), then having a membership_expiration column as well. If you want to track each membership purchase, you can have a separate transaction table that tracks purchases. This also gives you the ability to expand to other types of purchases or transactions in the future without modifying the data model.
How about adding a membership field to the users table with one of three values- null, monthly, or yearly?