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.
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'm creating a POS like system and I'm not really sure how to do the Shopping Cart part wherein after the cashier enters all the customer's item (from Inventory table), the items entered will have a single Transaction #, just like what we see in the receipts.
Should I put a Trans_No column in the Cart table? If yes, how will I handle the assigning of a single Trans_No to multiple items? I'm thinking of getting the last Trans_No and increment that to 1 then assign it to all the items in the shopping cart of the casher. But there's a huge possibility that if 2 cashiers are simultaneously using the system they both retrieve the same latest transaction # and will increment it both to 1 resulting to merging of 2 customers' order in to 1 single transaction/receipt.
What's the best way to handle this?
The data object on which your transaction id goes depends on the functional requirements of your application. If whatever is in a cart should share a transaction id, then the cart table is the right place for the transaction id.
Database systems offer a variety of features to prevent the concurrent increment problem you describe. The easiest way to avoid this is to use a serial data type as offered e.g. by PostgreSQL. If you declare a column as serial, the database will care for generating a fresh value for each record you insert.
If no such data type is available, there might still be a mechanism for generating a unique primary key for a record. An example is the auto_increment directive for MySQL.
If all these are not viable for you, e.g. because you want to have some fancy logic of generating your transaction ids, putting the logic of reading, incrementing, and storing the value needs to be enclosed in a database transaction. Statements like
start transaction;
select key from current_key;
update current_key set key = :key + 1;
commit;
will prevent collisions on the key value. However, make sure that your transactions are short, in particular that you don't leave a transaction open during a wait for user input. Otherwise, other users' transactions may be blocked too long.
I am working on banking application, I want to add a feature of maker,checker and authorize for every record in a table. I am explaining in below details
Suppose I have one table called invmast table. There are 3 users one is maker, 2nd one is checker and last one is authorize. So when maker user creates a transaction in database then this record is not live (means this record can not be available in invmast table). Once checker checked the record and authorizer authorized the record the record will go live ( means this record will insert in invmast table ). Same thing is applicable for update and delete also. So I want a table structure how to achieve this in real time. Please advice if any.
I am using vb.net and sql server 2008
Reads like a homework assignment.....
Lots of ways to solve this, here's a common design pattern:
Have an invmast_draft table that is identical to invmast but has an additional status column in the table. Apps need to be aware of this table, status column and what its values mean. In your case, it can have at least 3 values - draft, checked, authorized. Makers first create a transaction in this table. Once maker is done, the row is committed with the value "draft" in the status column. Checker then knows there's a new row to check and does his job. When done, row is updated with status set to checked. Authorizer does her thing. When authorizer updates the status as "authorized" you can then copy or move the row to the final invmast table rightaway. Alternatively, you can have a process that wakes up periodically to copy/move batches of rows. All depends on your business requirements. All kinds of optimizations can be performed here but you get the general idea.
In an app that I am developing, we have users who will make deposits into the app and that becomes their balance.
They can use the balance to perform certain actions and also withdraw the balance. What is the schema design that ensures that the user can never withdraw / or perform more than he has, even in concurrency.
For example:
CREATE TABLE user_transaction (
transaction_id SERIAL NOT NULL PRIMARY KEY,
change_value BIGINT NOT NULL,
user_id INT NOT NULL REFERENCES user
)
The above schema can keep track of balance, (select sum() from user_transction); However, this does not hold in concurrency. Because the user can post 2 request simultaneously, and two records could be inserted in 2 simultaneous database connections.
I can't do in-app locking either (to ensure only one transcation gets written at a time), because I run multiple web servers.
Is there a database schema design that can ensure correctness?
P.S. Off the top of my head, I can imagine leveraging the uniqueness constraint in SQL. By having later transaction reference earlier transactions, and since each earlier transaction can only be referenced once, that ensures correctness at the database level.
Relying on calculating an account balance every time you go to insert a new transaction is not a very good design - for one thing, as time goes by it will take longer and longer, as more and more rows appear in the transaction table.
A better idea is to store the current balance in another table - either a new table, or in the existing users table that you are already using as a foreign key reference.
It could look like this:
CREATE TABLE users (
user_id INT PRIMARY KEY,
balance BIGINT NOT NULL DEFAULT 0 CHECK(balance>=0)
);
Then, whenever you add a transaction, you update the balance like this:
UPDATE user SET balance=balance+$1 WHERE user_id=$2;
You must do this inside a transaction, in which you also insert the transaction record.
Concurrency issues are taken care of automatically: if you attempt to update the same record twice from two different transactions, then the second one will be blocked until the first one commits or rolls back. The default transaction isolation level of 'Read Committed' ensures this - see the manual section on concurrency.
You can issue the whole sequence from your application, or if you prefer you can add a trigger to the user_transaction table such that whenever a record is inserted into the user_transaction table, the balance is updated automatically.
That way, the CHECK clause ensures that no transactions can be entered into the database that would cause the balance to go below 0.
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.